afterCommit is being called before the actual sql commit in ConnectionManagerImpl.
localCommit. Is this the intent?
TransactionImpl.commit calls
* TransactionImpl.prepare indirectly calls
* beforeCommit
* beforeUpdate (or Insert, or Delete)
* sql update, or insert, or delete
* afterUpdate (or Insert, or Delete)
* afterCommit
* PersistenceBrokerImpl.commitTransaction calls
* ConnectionManagerImpl.localCommit calls
* sql commit
This would have to be resequenced slightly to get afterCommit called after the
sql commit.
The reason why I'm asking is that we are storing blob data outside the database.
We are using the after callbacks to implement rollback for these.
The ojb-maintained persistent field is a relative pathname to the binary file.
The blob is a transient field in the persistent class. A persistent timestamp
field ensures update if the blob is modified and no other field is.
The basic approach to rollback here is
* afterInsert
* write the transient field to <file>
* state = afterInsert
* afterUpdate
* copy <file> to <file.rollback>
* write the transient field to <file>
* state = afterUpdate
* afterDelete
* rename <file> to <file.deleted>
* delete <file.rollback>
* state = afterDelete
* afterAbort
* state == afterInsert
* delete <file>
* state == afterUpdate
* rename <file.rollback> to <file>
* state == afterDelete
* rename <file.deleted> to <file>
* finally
* transient field = null
* state = null
* afterLookup
* transient field == null
* read <file> into transient field
All the callbacks are synchronized.
The case of delete is slightly different than update. If the sql commit occurred
before the afterCommit was called then afterCommit could delete the save copy.
Otherwise an occasional sweep is needed to remove all the .deleted files.
================================================================================
The state keeping mentioned above is done by the after callbacks only so
hopefully this will work with optimistic locking. It appears that optimistic
locking LockNotGrantedExceptions are thrown at the point of sql update/delete.
* Depending on the cache could there be concurrent updating/deleting threads
in the object up to this point? It seems so.
* What about concurrent reading threads? It appears as though reading
threads only execute afterLookup/beforeCommit/afterCommit. But it looks
like afterAbort could be called in a reading thread and so could trigger
the actions mentioned above. Maybe keeping the insert/update/delete
state in a ThreadLocal could keep this from happening.
* We are currently using the odmg layer, and plan to cluster our application
in the future.
The ojb docs currently state
4.29. How to use OJB in a cluster
...
transactional isolation and locking
If you are using the PersistenceBroker API use optimistic locking (OL)
...
If you are working with the ODMG API distributed pessimistic locking
should be used, by setting the respective flag in OJB.properties.
Are there plans to support optimistic locking in the odmg layer in a
clustered configuration?
Is optimistic locking currently supported by the odmg layer in a
non-clustered configuration?
Thanks in advance,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
