Open plarsson opened 6 years ago
If I understand correctly, you're reporting that we are not using a balance cache that we could have used, but balance is still accurate, right?
Yes thats correct. It's just a performance issue
Perfect - will take a deep look and comment.
FYI, I'm testing the following change, trying to verify side-effects.
if (bcache != null && (maxId == 0 || bcache.getRef() <= maxId)) {
balance[0] = bcache.getBalance();
entryCrit.add (Restrictions.gt("id", bcache.getRef()));
}
Hi, did you find any issues with this fix?
Unfortunately we had a situation where balance_cache was not right. We are investigating if this was a DB procedure issue or something else. We are investigating. For the time being, I've temporarily reverted the change.
@ar How did they proceed with this case? We occasionally used to encounter similar situations. In balance-cache, there was a record pointing to an unconfirmed transaction at the SQL level, and when calculating the balance afterwards, it returned an incorrect value.
@cdanielpy what you report might be related to an issue with your transaction isolation configuration at the JDBC level. Could that be the case?
For example the balance cache is never used by FinalBalance min/max rules as it sends in a max id of 0 I think the balance cache should be allowed to use when maxId is sent in as 0?
See this line: https://github.com/jpos/jPOS-EE/blob/master/modules/minigl/src/main/java/org/jpos/gl/GLSession.java#L1072