If you have a huge quantity of process, I suggest to move your process
on persist job.
Calculate own split your process to permit the threading on multiple
server, think also about potential deadlock, and share the charge on
different ofbiz instance (it's possible to have them lite).
Nicolas
On 19/08/2025 15:22, Baranov, Alexander wrote:
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" <nicolas.ma...@nereide.fr
<mailto:nicolas.ma...@nereide.fr>> 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.
