You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by João Mota <jo...@ist.utl.pt> on 2003/12/18 16:29:47 UTC

3 questions about ODMG

->Using Pb with ODMG Question:

When you use the PB methods with the ODMG broker, the query includes the
objects touched by the current transaction?
If not this could lead to problems with locks if the cache is cleared (see
thread with title:  Multiple reads within the same transaction). We are
currently doing a second query for every object using the TransactionImpl
method getObjectByIdentity to avoid this problem. 

->Question About Locks and Reference Update:

When does OJB updates the references to the objects (by reference, I mean
the object and the integer that references the id of the object)?
The problems im having are best explained by the following example:

Lets say I have an object A that has references to B, C and D 

And within a transaction I do:


A xptoA = new A();
lockWrite(xptoA) ;
xptoA.setB(xptoB);
xptoA.setC(xptoC);
xptoA.setD(xptoD);

When commit is done all the references are updated except for the reference
to xptoB and so I get an exception because that field in the DB cannot be
null.

Then I changed the order of the instructions to: 
A xptoA = new A();
xptoA.setB(xptoB);
lockWrite(xptoA) ;
xptoA.setC(xptoC);
xptoA.setD(xptoD);

and now all the references are updated.

What I am trying to understand is the difference between B, C and D, so I
can understand why this happens.


-> Question About Firebird
Does OJB supports the FireBird DB and the construction of the plataform
profile for FireBird is just straightforward or are there any known issues?



Re: 3 questions about ODMG

Posted by Thomas Mahler <th...@web.de>.
Hi again,

Luis Cruz wrote:
<snip>
> 
> 
>>So if an object is registered to a tx and then selected by a query, then 
>>the same instance is returned by the query.
> 
> 
> I disagree. This is only true if the object is "cachable" and if an
> empty cache implementation is not used.

You are right. I simplified the situation a bit.

I just wanted to point out that if your instance is in the cache 
already, then the same instance is returned.

currently we have no other way to maintain object uniqueness.
See Armins explanation in the other thread.

cheers,
thomas

> Just my 2 cents,
> Luis Cruz
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 
> 


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


Re: 3 questions about ODMG

Posted by Luis Cruz <le...@netcabo.pt>.
On Fri, 2003-12-19 at 16:51, Thomas Mahler wrote:
> Hi João,
> 
> João Mota wrote:
> > ->Using Pb with ODMG Question:
> > 
> > When you use the PB methods with the ODMG broker, the query includes the
> > objects touched by the current transaction?
> 
> All queries, PB and OQL queries always are executed against the database.
> If an object returned by a query is in the cache already, the cached 
> instance is returned.

This is true.

> So if an object is registered to a tx and then selected by a query, then 
> the same instance is returned by the query.

I disagree. This is only true if the object is "cachable" and if an
empty cache implementation is not used.

Just my 2 cents,
Luis Cruz


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


Re: 3 questions about ODMG

Posted by Thomas Mahler <th...@web.de>.
Hi João,

João Mota wrote:
> ->Using Pb with ODMG Question:
> 
> When you use the PB methods with the ODMG broker, the query includes the
> objects touched by the current transaction?

All queries, PB and OQL queries always are executed against the database.
If an object returned by a query is in the cache already, the cached 
instance is returned.
So if an object is registered to a tx and then selected by a query, then 
the same instance is returned by the query.

> If not this could lead to problems with locks if the cache is cleared (see
> thread with title:  Multiple reads within the same transaction). We are
> currently doing a second query for every object using the TransactionImpl
> method getObjectByIdentity to avoid this problem. 
> 

Yup, emtying the cache in the middle of a tx will have an impact on 
later queries. I'll have a look at the other thread...

> ->Question About Locks and Reference Update:
> 
> When does OJB updates the references to the objects (by reference, I mean
> the object and the integer that references the id of the object)?
> The problems im having are best explained by the following example:
> 
> Lets say I have an object A that has references to B, C and D 
> 
> And within a transaction I do:
> 
> 
> A xptoA = new A();
> lockWrite(xptoA) ;
> xptoA.setB(xptoB);
> xptoA.setC(xptoC);
> xptoA.setD(xptoD);
> 
> When commit is done all the references are updated except for the reference
> to xptoB and so I get an exception because that field in the DB cannot be
> null.
> 
> Then I changed the order of the instructions to: 
> A xptoA = new A();
> xptoA.setB(xptoB);
> lockWrite(xptoA) ;
> xptoA.setC(xptoC);
> xptoA.setD(xptoD);
> 
> and now all the references are updated.
> 
> What I am trying to understand is the difference between B, C and D, so I
> can understand why this happens.

Hmm, without knowing your real sourcecode, the persistent classes and 
their mapping, any answer would be guesswork...

> 
> 
> -> Question About Firebird
> Does OJB supports the FireBird DB and the construction of the plataform
> profile for FireBird is just straightforward or are there any known issues?
> 

As you can see by the enormous list of PlatFormImpls that we already 
have, it's quite straightforward to adapt OJB to other platforms.
We even provide support for MsAccess! which differs a lot from "normal" 
RDBMS.
I don't know of any reasons, why FireBird should cause problems.

cheers,
Thomas

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


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