ODMG: caching accross several consecutive transactions?

[ol...@ppi.de]

Hello,

I would like to repeat a question that had been asked by Kevin Viet (20 Dec
2002)
without any reply.

Suppose I do the following in ODMG:

txn.begin();
txn.lock(x); // or retrieve x by query, does not matter.
txn.commit()

txn.begin()
y = ... // retrieve the same object as above by a suitable query 
assertTrue(x == y); // fails
txn.commit();

In the second transaction, the objects are not found in the cache,
so the assert fails.I had a quick look into the code and I think this is due
to the fact
that the second transaction (or rather, the second begin/commit-phase
of that single transaction) uses a fresh PersistenceBroker.

When you do the above with the PB API, the assert will not fail, provided
the second begin/commit uses the same PersistenceBroker.

I do think that this behaviour is correct according to the ODMG spec,
but this should not prevent us from targetting something more convenient.

In the Poet/FastObjects flavour of ODMG, there is a concept added to ODMG
which is
very similar to the PersistenceManager in JDO. It is
called "ObjectManager".  Such an ObjectManager can be used to bracket
together
several consecutive transactions, such that object identity is quaranteed
for 
all persistent objects accessed in these transactions.

Question:
Is there a way to achieve such behaviour with the current OJB ODMG API?
If not, I bet it is simple to implement because is it present in JDO anyway.

Oliver

Re: ODMG: caching accross several consecutive transactions?

[Thomas Mahler <th...@apache.org>]

Hi Oliver,

oliver.matz@ppi.de wrote:
> Hello,
> 
> I would like to repeat a question that had been asked by Kevin Viet (20 Dec
> 2002)
> without any reply.
> 
> Suppose I do the following in ODMG:
> 
> txn.begin();
> txn.lock(x); // or retrieve x by query, does not matter.
> txn.commit()
> 
> txn.begin()
> y = ... // retrieve the same object as above by a suitable query 
> assertTrue(x == y); // fails
> txn.commit();
> 
> In the second transaction, the objects are not found in the cache,
> so the assert fails.I had a quick look into the code and I think this is due
> to the fact
> that the second transaction (or rather, the second begin/commit-phase
> of that single transaction) uses a fresh PersistenceBroker.

It's not the usage of the fresh broker, as currently all brokers use the 
same cache.
But on commit of a transaction all objects touched during the tx are 
invalidated. In singlevm mode this simply results in removing them from 
the cache.

This is a known issue (see bug database)

> 
> When you do the above with the PB API, the assert will not fail, provided
> the second begin/commit uses the same PersistenceBroker.

Yes, because PB transactions do not invalidate objects on commit() !

> I do think that this behaviour is correct according to the ODMG spec,
> but this should not prevent us from targetting something more convenient.
> 
> In the Poet/FastObjects flavour of ODMG, there is a concept added to ODMG
> which is
> very similar to the PersistenceManager in JDO. It is
> called "ObjectManager".  Such an ObjectManager can be used to bracket
> together
> several consecutive transactions, such that object identity is quaranteed
> for 
> all persistent objects accessed in these transactions.
> 
> Question:
> Is there a way to achieve such behaviour with the current OJB ODMG API?

IMO it's not possible without code modifications.

> If not, I bet it is simple to implement because is it present in JDO anyway.

I agree. It would be most easy to use a "NonInvalidatingCache" that does 
not remove objects on invalidation.
Could be written by inheriting from the DefaultCacheImpl within 5 Minutes.

cheers,
Thomas


> Oliver
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 
> 
>