Hello Nicolas,
Thank you for your reply! I am writing to express my concern regarding the planned mass posting of financial documents. My primary worry is that processing a large number of transactions simultaneously could lead to database process locks or inconsistencies in the total amounts. Since each individual transaction updates a shared total amount, the sequence of operations is critical to maintain data integrity. The standard process for each transaction is: * SELECT the current value. * CALCULATE the new value (add/subtract). * UPDATE the record with the new total. If this sequence is not strictly enforced for every transaction (e.g., through row-level locking or a queue), there is a risk of race conditions where two processes read the same value simultaneously, leading to an incorrect final total after both updates. Given that the entity engine's default behavior might not explicitly prevent this, could you please advise on the best practices or built-in mechanisms to handle this scenario safely? Are there any safeguards in place to ensure atomicity and consistency during bulk operations? Thank you for your insights. Best regards, Alex. On 19.08.2025, 12:28, "Nicolas Malin" <[email protected] <mailto:[email protected]>> wrote: Hello Alexander, Use seca system on service who do the commitment. When the service is called, you run as action the record of glAccountHistory Nicolas On 13/08/2025 14:31, Baranov, Alexander wrote: > Dear OFBiz Community, > > > > In Apache OFBiz, the GlAccountHistory table is populated during the period > closing process. For reporting purposes, it would be valuable to update this > table after each accounting document is committed, enabling real-time > insights into the current period. > > Is there an existing mechanism or recommended approach in OFBiz to update the > GlAccountHistory table immediately after each accounting transaction is > committed? > > > > Thank you for your guidance, and I look forward to your insights or > recommendations. > > Best regards, > > Alexander Baranov.
