db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <guillaume.no...@deliasystems.com>
Subject RE: Bug in batch mode
Date Fri, 06 Feb 2004 08:58:02 GMT
Hi Oleg,

I'm working with the lastest cvs version, and yes the problem occurs.
The problem you solved few days ago was due to foreign keys.
This one occurs when deleting an object and then storing it.

When deleting the object, the delete statemtents are kept in memory
and not send to database, dut to the batch connection. But when the
a new copy is stored just after that, ojb tries to materialize it
with a select statemtent on the primary key (which in my case is not
computed by ojb nor database). As the delete statement has not been
sent to database yet, the select statement returns a valid row.
So the broker thinks the object is in database and performs an update
on this row. When the update is sent to the batch connection, it sees
that the same table has already been touched, so it sends the batch
containing the delete statement. When the next batch is executed, the
update statement is performed on a non valid row. (For my tests, i'm
using Oracle, and the update statement did not return an error, but
the error occured when inserting objects with foreign keys on it,
but that's not the point).

This is a workaround for another problem i want to expose right now:
i'm using a strongly hierarchical object model. I mean that i have
36 different tables to store my objects, but only 9 of them are "main"
objects that we use directly. Other tables contains sub-objects (objects
that are in collections of "main" object or other "sub-objects") that
should not be materialized by themselves. The main purpose of my project
is to synchronize our data (which are not stored in a RDMS).
We've got two operations that we performed thanks to ojb (which is a
very remarkable product):
  * in the first one, we make an initialization of data. All data are
retrieved from our data source and we store objects in an empty database.
That's the first part on which we have performance problems (see my
previous mail to Armin)
  * in the second one, we are in synchronization mode. We receive objects
that have been changed from our data source and store an updated copy them
with ojb. So here comes the problem.

When i receive an updated copy of a "main" object. At first, i called the
store method on the broker, giving it the new copy of my object. The problem
is that ojb is not aware that "sub-objects" should be deleted because i'm
not
modifying an ojb-aware object, i use a completely new copy of the object.
So the store method did not delete old sub-objects collections. That's
the reason why i do a delete, immediately followed by a store.
I think this may be a great problem for other ojb users.

I apologize for this long mail, but i want my problems to be as clear as
possible.

Regards,

Guillaume Nodet

-----Message d'origine-----
De : Oleg Nitz [mailto:on@ukr.net]
Envoyé : vendredi 6 février 2004 01:13
À : OJB Developers List
Objet : Re: Bug in batch mode


Hi Guillaume,

Have you tried the CVS version?
I think this bug was recently fixed both in HEAD and in the OJB_BRANCH_1_0

Regards,
 Oleg

On Thursday 05 February 2004 18:16, Guillaume Nodet wrote:
> Because of a problem i have using collections,
> i can not directly use a store on my object
> to save it in the database. I need to perform
> first a delete and then a store (as ojb does not
> delete old objects from collections, and that i
> think is another bug...).
> The problem arise when i want to use batch mode.
>
> Let's examine the following code:
> 	broker.delete(a);
> 	broker.store(a);
> It should leads to the following sql statements:
> 	DELETE FROM A WHERE ...
> 	SELECT FROM A WHERE ...   // materializing
> 	INSERT INTO A
>
> The problem arise in batch mode:
> 	* the delete statement is kept in memory
> 	* the select is done and returns a row
> 	* so an update is send to the database and fails
>
> Regards
>
> Guillaume
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org


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





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


Mime
View raw message