Affects Version/s: 6.2.0 CE M2
Fix Version/s: 6.2.0 CE M2
For a very long time(from day 1, maybe), we flush out hibernate session right after each persistent operation by default.
We had the BatchSession utility class to group several persistent operations into one flush to improve performance only under some very special scenarios. Like import/export, etc.
This design is against hibernate's FlushMode infrastructure. Flush after every persistent operation is causing more frequent network traffic to database, and more importantly, if the persistent operation involves row locks, this pattern will significantly increasing the lock holding time on db side. On the other side, even we try to group persistent operation in batch with BatchSession, due to we default to hibernate auto FlushMode, hibernate will do automatically flush anyway underground if it sees necessary. So in general, BatchSession is not doing us any good, but increase complexity and runtime overhead.
This change completely removes BatchSession, now we depends on hibernate's auto flush to automatically synchronize with database at proper time. This will most likely group a few persistent operations into one flush, depends on the use case.
The pros for this are:
1) Under certain scenarios, this can reduce network traffic to database
2) In average, this can reduce row locks holding time on database side, and less thread blocking time on portal side.
The cons for this is:
1) Grouping persistent operation under certain scenarios will increase the chance seeing concurrent modification confliction.
This conflicting can not be avoid, with BatchSession, we are as if using pessimistic locking, which reduce the chance seeing concurrent modification with the price of lower concurrency. Without BatchSession we are as if using optimistical locking, in some cases we increase the chance seeing concurrent modification confliction, but in average we get better concurrency.