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 Julio Barros <Ju...@E-String.com> on 2003/03/27 18:42:08 UTC

OJB/ODMG Question

Hi,

I've got a question about how to do updates on persistent objects
using JDO's ODMG Api.  I would look at the mailing list archive but it
does not seem to be working.  I've also looked at the apache jdo
website and there is a lot information there and I was wondering if
anyone had any links to other tutorials or examples.

I've looked at tutorial 2, especially UCEdit, which works fine and I
understand what it is doing.  That use-case, starts a transaction,
gets an object, gets a write lock, modifies the object, and then
commits the transaction.

The thing is that I would like to modify an object in a different
layer that is not db aware.  I would like to use a db manager layer to
do the reads and writes.  If I've gotten the object in one transaction
that was commited and then modified the object outside of a
transaction, what should the save method look like?

What I first tried to do was, start a transaction, get a write lock,
commit the transaction. But that did not work probably because the
lock did not detect a change in the object.  I then tried to, start a
transaction, query for the object, copy the values into the new
object, commit the transaction.  But that did not work either, I'm
guessing because my second query retrieved the object from the cache
and then the transaction did not detect an actual change in the object
since the lock was acquired after the object was really modified.

Is there a way to mark the object "dirty"?  Do I need to remove it
from the cache?  Is there a simpler solution?  What am I overlooking?
Also, is there a good reference for OQL?

Thanks in advance,

Julio



Re: OJB/ODMG Question

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

Julio Barros wrote:
> Hi,
> 
> I've got a question about how to do updates on persistent objects
> using JDO's ODMG Api.  I would look at the mailing list archive but it
> does not seem to be working.  I've also looked at the apache jdo
> website and there is a lot information there and I was wondering if
> anyone had any links to other tutorials or examples.
> 
> I've looked at tutorial 2, especially UCEdit, which works fine and I
> understand what it is doing.  That use-case, starts a transaction,
> gets an object, gets a write lock, modifies the object, and then
> commits the transaction.
> 
> The thing is that I would like to modify an object in a different
> layer that is not db aware.  I would like to use a db manager layer to
> do the reads and writes.  If I've gotten the object in one transaction
> that was commited and then modified the object outside of a
> transaction, what should the save method look like?
> 
> What I first tried to do was, start a transaction, get a write lock,
> commit the transaction. But that did not work probably because the
> lock did not detect a change in the object. 

correct! the ODMG transaction manager can only detect changes made 
within the same transaction.

> I then tried to, start a
> transaction, query for the object, copy the values into the new
> object, commit the transaction.  But that did not work either, I'm
> guessing because my second query retrieved the object from the cache
> and then the transaction did not detect an actual change in the object
> since the lock was acquired after the object was really modified.

correct again.
ODMG has no notion of long transactions. That's why you have to to the 
swizzling on your own.
To store an updated object X
You have to:
1. remove X from cache (with a PersistenceBroker call)
2. start the tx
3. query the db version of X (X') from the database.
    (On querying it gets automatically locked to the transaction)
4. set all attributes of X' to the corresponding values of X
5. commit the tx

> 
> Is there a way to mark the object "dirty"?  Do I need to remove it
> from the cache?  Is there a simpler solution?  

Using the PersistenceBroker API for your db manager layer could be much 
easier than using ODMG for that purpose.

The ODMG programming model is not very well suited for such a manager.
The ODMG programming model assumes that your business logic makes direct 
use of ODMG transactions.

> What am I overlooking?
> Also, is there a good reference for OQL?

http://www.poet.com has excellent ODMG resources in the developer section.

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