Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Subject: Question about transaction rollback
To: ojb-dev@db.apache.org
Message-ID: 
 <OFD4B10480.98F980DA-ON85256DB4.005C8477-85256DB4.006291F2@fin.equifax.com>
From: Dave.Derry@Equifax.com
Date: Fri, 3 Oct 2003 13:57:31 -0400
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi,

I just upgraded from RC1 to RC4, and have encountered unit test failures. Now
these are NOT OJB unit tests; but the unit tests for our project. The problem (at
least in the one case that I have examined so far) is the result of an aborted
transaction.

I've traced the problem to the addition in StateOldDirty#rollback(ObjectEnvelope
mod, PersistenceBroker broker) of the following line:

        mod.rollback();

ObjectEnvelope#rollback() then attempts to restore the state of the object.
Although I applaud this attempt, I have 2 concerns with this approach.
ObjectEnvelope #rollback() is only able to restore fields that are included in
the class descriptor; any transient fields that may have been changed will not be
restored. Looking at the ObjectEnvelope#rollback() code shows that you don't have
an answer for my second concern, which is, how do you rollback a collection?

But to address my first concern. I have reviewed Klaasjan Brand's message
regarding inconsistency of cached objects after a rollback, and certainly
understand his concern. But, although his patch, helps to alleviate the problem,
he has not solved the problem, for the reasons I stated above.  Unless we can
guarantee that an object is fully restored to it's pre-modification state, it is
safer to flush the object from the cache (as we have done on my current project).
Now granted, the unit test failure that I mentioned is caused by our expectation
of the old behavior, and is merely due to the fact that we assert that the object
has been modified. But since it has been flushed from the cache, it is only
through a 'dangling' reference that we can even see it. So my unit test failure
(at least this one) isn't a big concern for me. It's just that the failure got me
looking for what had changed, and when I found it I had to question the validity
of the change. True, this change may actually effect a rollback in a large
percentage of cases, but it could result in subtle problems in the remaining
cases. Is it possible to do better?

My 2 cents,
Dave Derry


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org