[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipselink-dev] CommitManager.commitDepth issue EclipseLink 2.6.4

Hi Dev Team,

 'first time on the customer end of this mailing list :-)

 I am seeing an issue with commitManager (admittedly in a bit of a strange usecase) and wondering if you have seen this before.

 I am persisting a reasonably simple object. (no relationships, but does have some MappedSuperClasses in the hierarchy and a couple of @Lob mappings). I persist it via em.persist() and all is good.

 Now I want to update it. To avoid the existence check, instead of using the an em directly, I unwrap the em's ClientSession and execute an UpdateObjectQuery on the client session (a new em is used every time I do this). This mostly works, but under highly concurrent situations, the CommitManager associated with the ClientSession appears to get corrupted. I see that the commitDepth somehow gets permanently stuck in a state that is > 0 (it is 1) and once that happens the 2nd time I try to update an object using the strategy above, it will not update.

 It looks like the following is happening

1. In commitManager.markCommitCompleted(), when the depth doesn't get to 0, we never call reinitialize() to clear the state of the commitManager. (we commitState has a massive number of objects by the time I can observe the issue)

2. Because it is never cleared after the first update, in DatabaseQueryMechanism.executeWrite(), we bail out on the following statement and never update:

ÂÂÂÂÂÂÂ if (commitManager.isCommitCompletedInPostOrIgnore(object)) {
ÂÂÂÂÂÂÂÂÂÂÂ return object;
ÂÂÂÂÂÂÂ }

Is this a familiar problem? I didn't find anything obvious in the bug db.

-Tom