db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Klaasjan Brand <klaasjan.br...@topicus.nl>
Subject RFI / PATCH: inconsistent cached objects after transaction rollback?
Date Mon, 28 Apr 2003 09:07:42 GMT
Hello,

We've found a problem concerning rollbacks and objects in the OJB
default cache:
When committing an update to an object which generates an SQL exception
(fi. duplicate key instance) the object in the OJB cache is not rolled
back to its initial state.
It seems that when an exception is thrown., OJB will try to abort the
current transcaction and call ObjectEnvelopeTable.rollback().
But that call doesn't have any effect anymore because all the objects
that commit is called on already have a StateOldClean so no rollback
will be performed.

The attached patch changes the behaviour so that

 mod.manage(mod.getObject());
 mod.setModificationState(StateOldClean.getInstance());

won't be called in commit an checkpoint, and adds a step 5 in
ObjectEnvelopeTable.commit()

 // 5.Update all Envelopes to new CleanState
 setCleanState();

that will set the clean state after the sql executes.

The patch adds an ObjectEnvelope.rollback method that is called by
StateOldDirty.rollback method. It tries to rollback as many fields as
possible but Collections and Proxy (Virtual or not) can't be rolled back
because those values are not stored only some kind of Dirty Mark or
Identity object.

(attached patch by Johan Compagner)

PS. We can work around the problem by using the per broker cache
implementation, but the default global cache should be correct as well.

-- 
Klaasjan Brand <klaasjan.brand@topicus.nl>
Topicus B.V.

Mime
View raw message