Moving Entity instances from L2 to L1 cache When OLE Occurs in a Clustered High Volume Environment. (Doc ID 2473131.1)

Last updated on OCTOBER 17, 2022

Applies to:

Symptoms

In a high-volume and clustered environment, when entity characteristics are updated concurrently, there is a likelihood of optimistic locking exceptions occurring. Such (volatile) data that is likely to change frequently needs to be moved to isolated cache. This knowledge management article describes the procedure to move entity data caching from shared cache to isolated cache.

The following snap-shot shows a thread trying to update stale data due to a delay in shared cache synchronization and leading to an Optimistic Locking Exception (OLE):

ExecuteThread: '13'

Updated Service_char with Entity ID'53329215900001' to version '3' from '2':

[EL Fine]: sql: 2018-02-23 20:40:24.693--ClientSession(1787292159)--Connection(167728237)--Thread(Thread[[ACTIVE] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads])--UPDATE SERVICE_CHAR SET VALUE = ?, LASTMODIFIEDUSER = ?, LASTMODIFIEDDATE = ?, ENTITYVERSION = ? WHERE ((ENTITYID = ?) AND (ENTITYVERSION = ?))

                bind => [Inactive, <anonymous>, 2018-02-23 20:40:24.69, 3, 53329215900001, 2]

ExecuteThread: '7' OLE when to tried to Updated Service_char with Entity ID'53329215900001' to version '3' from '2' again means trying to update on the Stale Data:

[EL Fine]: sql: 2018-02-23 20:40:47.868--ClientSession(1699796055)--Connection(1242164930)--Thread(Thread[[ACTIVE] ExecuteThread: '7' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads])--UPDATE SERVICE_CHAR SET VALUE = ?, LABEL = ?, LASTMODIFIEDDATE = ?, ENTITYVERSION = ? WHERE ((ENTITYID = ?) AND (ENTITYVERSION = ?))

                bind => [Activate, Activate, 2018-02-23 20:40:47.866, 3, 53329215900001, 2]

[EL Warning]: 2018-02-23 20:40:47.872--UnitOfWork(497340344)--Thread(Thread[[ACTIVE] ExecuteThread: '7' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads])--Local Exception Stack:

Exception [EclipseLink-5011] (Eclipse Persistence Services - 2.5.2.v20140319-9ad6abd): org.eclipse.persistence.exceptions.OptimisticLockException

Problem:

Some threads are always reading stale data even though there is an immediate read or a delayed read by thread2 after a thread1 updates it.  The problem can occur on single node or multi-node clustered environments.

Changes

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.