Performance issue - Cache not being used in some cases

Description

Hi, while refactoring MSequence to solve the ticket IDEMPIERE-1146: Centralized ID not working with native sequence enabledClosed - I noticed a very bad performance issue because for certain tables the Cache was not being used - in my tests this was mostly AD_RecentItem, but after I added the attached patch

it seems the problem is wider.

It's probably caused by some context not correctly set for multi-threading.

The issue is: the MTable.get methods find the required object in the cache, but is discarded because the context is different, so it goes again to read the record to the database, and if the code requires to get a column (like it was in MSequence) then all the columns are read again from database.

Environment

None

Attachments

2

Activity

Heng Sin Low
September 27, 2020 at 8:42 AM
Heng Sin Low
May 20, 2020 at 6:04 AM

Added patch to illustrate the issue of having PO with plain properties context in cache.

Heng Sin Low
May 19, 2020 at 1:56 PM

To be safe, we probably should log a warning and ignore the call to put such PO into CCache.

For example:

  • User1 put PO1 with properties that contains User1 session details into cache

  • User2 get PO1 from cache

  • We have many get method that doesn’t validate ctx and with those methods, User2 will get PO1 from cache that contains User1’s session details!

Carlos Ruiz
May 19, 2020 at 1:19 PM

> getCtx() is an instance of ServerContextPropertiesWrapper
And add a warning here - it doesn't sound good having objects where the context is not the intended context of the whole application?

Heng Sin Low
May 19, 2020 at 12:56 PM

Properly only safe to put a PO into the global static cache (CCache) if it fulfill the following conditions:

  • getCtx() is an instance of ServerContextPropertiesWrapper

  • get_TrxName() == null

  • is make readonly

Duplicate

Details

Assignee

Reporter

Priority

Created May 11, 2020 at 10:48 AM
Updated November 1, 2020 at 4:09 PM
Resolved September 27, 2020 at 8:42 AM