[eclipselink-dev] CommitManager.commitDepth issue EclipseLink 2.6.4

[Tom Ware <tom.ware@xxxxxxxxxx>]

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