db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: [OTM] bug with most simple use case - the story goes on :)
Date Thu, 22 Apr 2004 15:12:11 GMT
Joerg Heinicke <joerg.heinicke <at> gmx.de> writes:

> Hello,
> I have found another bug in OJB OTM when doing long transactions. What's
> strange about it is that it is probably the most simple use case.

Today I did the first update on OJB after Oleg's refactoring of OTM. Everything
seems to work so far except the use case mentioned below - this one is even
worse than before.

The reason is simple and seems to be due to the refactoring:
In the test case below in the method updateAddresses() the elements in
newAddresses and in oldAddresses are no longer the same and so the test
contains() returns always false, every element is deleted. This could probably
fixed by implementing equals() and hashcode() correctly.

But in theory the current situation (without having implemented equals() and
hashcode() correctly) should result in a complete delete of all elements in
oldAddresses and complete readd of all elements in newAddresses, shouldn't it?

At least it does not. The elements that have been equal before the refactoring,
but are now deleted - because they are no longer equal in the sense of equals()
- are *not* readded when calling makePersistent() on them as it is done with the
second loop iterating over newAddresses. So in every iteration all already
existing addresses are lost and only newly added addresses live - up to the next
iteration only again!

The test case below is somewhat insufficient for the new error as it tests only
correct updates, but not existence of the address at all:

>     public void testSomethingSimple() throws Throwable {


>         addresses = this.getAddresses();

// this additional check is missing
assertEquals("Collection of addresses must be 1. ", 1, addresses.size());

>         iter = addresses.iterator();
>         while (iter.hasNext()) {

BTW, did this test case made it into the CVS? I searched it, but could not find

Thanks for any effort fixing it finally :)


> The symptom: I can create and delete persistent objects, but I can not update
> them. First I retrieve the objects via getCollectionByQuery(). Later I iterate
> over the old Collection and call deletePersistent() for no longer existing
> objects, and iterate over the new Collection and call makePersistent() for new
> and updated objects.
> When doing remote debugging I see that the objects have the correct values
> immediately before makePersistent() - and after it. But no update on the
> database is done (through profileSql=true for MySQL I can see the fired SQL
> statements). Even the next call to getCollectionByQuery() returns the objects
> with the correct values that are not in the database though a SELECT on the
> database is done.
> Please find the test case below. If you remove the conn.invalidateAll() you
> will see the expected behaviour, no error is reported. But when not getting
> the objects from the cache you see that no update was done.
> Thanks in advance,
> Joerg

gmane.org complains about "There's much more quoted text in your article than
new. Prune quoted stuff.", so I only link to the test case:

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

View raw message