Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Batch Inserting and OptimisticLock 
Hello,

we have identified the "problem":
* we use TimestampLockingPolicy as described below. Its initialized by
default with useServerTime property. Therefore every update or insert
-Statement results in a Select sysdate ...
* For every Select sysdate following code is executed: 
---cut---
/org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor (Line 561) 
        if (isInBatchWritingMode(session)) {
            // if there is nothing returned and we are not using optimistic
locking then batch
            //if it is a StoredProcedure with in/out or out parameters then
do not batch
            //logic may be weird but we must not batch if we are not using
JDBC batchwriting and we have parameters
            // we may want to refactor this some day
            if (*dbCall.isNothingReturned()* && (!dbCall.hasOptimisticLock()
|| getPlatform().canBatchWriteWithOptimisticLocking(dbCall) ) 
                && (!dbCall.shouldBuildOutputRow()) &&
(getPlatform().usesJDBCBatchWriting() 
|| (!dbCall.hasParameters())) && (!dbCall.isLOBLocatorNeeded())) {
                // this will handle executing batched statements, or
switching mechanisms if required
                getActiveBatchWritingMechanism().appendCall(session,
dbCall);
                //bug 4241441: passing 1 back to avoid optimistic lock
exceptions since there   
                // is no way to know if it succeeded on the DB at this
point.
                return Integer.valueOf(1);
            } else {
               
*getActiveBatchWritingMechanism().executeBatchedStatements(session);*           
}
        }/---paste---

* dbCall.isNothingReturned() is true in this situation and
getActiveBatchWritingMechanism().executeBatchedStatements(session) is
executed.
* Thus the size of the batch-list is maximum one ...

possible solutions are:
* change the OptimisticLockPolicy to use local-time. the possible risk is
having inconsistent timestamps in order to wrong local-times.

our workaround (we want to use serverTime(dataBaseTime) for our
versionTimestamps):
* we use a own optimisticLockPolicy, which we set with a sessionCustomizer
* in our policy we ask the database once per session and keep the delta to
the localtime in a ThreadLocal for this session
* as long the session lives we calculate the dataBaseTime out of localTime
an saved delta
* we use commit- and rollbackListener for cleanUp the ThreadLocal
session-data. 

Stefan



--
View this message in context: http://eclipse.1072660.n5.nabble.com/Batch-Inserting-and-OptimisticLock-tp161429p162991.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.

Back to the top