TwoLevelCache troubles and get the running transaction

[Bruno CROS <br...@gmail.com>]

  Hi all,  hi Armin,

Using TwoLevelCacheObjectImpl, i experienced some big troubles  with  a
delete sequence containing some flush() to avoid FK constraints errors.

Assume 2 classes A and B, with 1:n relation.
We can resume sequence as this :

- open tx
- read object A
- read collection of object B
{
 - lock object B
 - set null to reference object A in B object
}
- flush() (with TxExt method) (normally database FK are null now for
database connection)
- read collection of object B
{
  - delete B ( database.deletePersistent method)
}

- commit tx

The troubles don't occur with DefaultObjectCacheImpl.
Hum, did i miss another way to flush database with 2LCache ?


Another question ( different) :
Is there a way to get the running transaction without no reference as
Transaction (kind of join with the running thread) ? in the way to get the
broker of the transaction.


Regards

Re: TwoLevelCache troubles and get the running transaction

[Bruno CROS <br...@gmail.com>]

  Hi armin,

I have post my migration changes to all my team. I approxymately get all
the transactions running ( except the  primitive at 0 changes !!! we had
just one PK using 0 value, ouf... ). Some little changes so. Now we are in
1.0.4. But I continue to search to install TwoLevelCache and CGLib,
convinced it's better, of course.

I answered to you below in blue.

On 2/11/06, Armin Waibel <ar...@apache.org> wrote:
>
> Hi Bruno,
>
> Bruno CROS wrote:
> >   Hi all,  hi Armin,
> >
> > Using TwoLevelCacheObjectImpl, i experienced some big troubles  with  a
> > delete sequence containing some flush() to avoid FK constraints errors.
> >
> > Assume 2 classes A and B, with 1:n relation.
> > We can resume sequence as this :
> >
> > - open tx
> > - read object A
> > - read collection of object B
> > {
> >  - lock object B
> >  - set null to reference object A in B object
> > }
> > - flush() (with TxExt method) (normally database FK are null now for
> > database connection)
> > - read collection of object B
>
> why do you read the collection again? How do you read the collection of
> B? When using a different PB instance (outside of the running odmg-tx)
> you will not see any changes till commit.
>
> Why don't you simply lock B, nullify the FK to A, delete B and commit or
> flush()?


Consider that what i gave you, is a simplier example. Problems occurs with
multi crossed object relations (B collection of A, but C collections of A
too, and C refers 1:1 to B). So, these steps  (double collection loops) are
needed to avoid FK errors. Despite that i have well ordered object
operations ( nullify the FK and then deletes ) of ODMG transactions, the
queries sequence (sended at commit) are not in the same order ( delete
before nullify !!). I suppose that's because, at start of coding, one year
ago, we used to delete objects with a PB method (out of tx i guess, missed,
sorry !!). Now we used a database.deletePersistent method. But if i well
remember, the need to flush to database (nullify) before the deletes is the
same ( consider DefaultObjectCacheImpl running, so...).

I understand now why flush is not effective to database with 2LevelCache,
thanks. All is done at commit, well. What i don't understand is that, even
if with 2LCache, flush don't really flush (i guess),  the sequence of
queries is still not the correct order (code order same as db logical order)
at the end. Does this means that i have to checkpoint() instead of flush()?
Tell me not !! I can't.

How can i change my transactions, to be sure that the order of queries is
the needed database logical order? ( in the way to use 2LCache )

> {
>   - delete B ( database.deletePersistent method)
> }
>
> - commit tx
>
> The troubles don't occur with DefaultObjectCacheImpl.

in the default cache you will always immediately "see" any changes of
any object (the "dirty read" problem discussed in a previous mail)

Ok.

> Hum, did i miss another way to flush database with 2LCache ?
>
>
> Another question ( different) :
> Is there a way to get the running transaction without no reference as
> Transaction (kind of join with the running thread) ? in the way to get the
> broker of the transaction.

Think I didn't catch the sentence. Nevertheless I will try to give an
answer. A different thread can join a running tx using
Transaction.join() method. To get the running tx of the current thread
call Implementation.currentTransaction()

OK.Thanks. Good. These is to code standalone object read method. I have many
object reads done with defaultPB. According to you, i understand that it
will better to use the transaction PB.
So object read methods, can run within or without a transaction (if objects
are modified and read several times, it will be safe, i guess).



regards,
Armin

>
>
> Regards
>

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

Re: TwoLevelCache troubles and get the running transaction

[Armin Waibel <ar...@apache.org>]

Hi Bruno,

Bruno CROS wrote:
>   Hi all,  hi Armin,
> 
> Using TwoLevelCacheObjectImpl, i experienced some big troubles  with  a
> delete sequence containing some flush() to avoid FK constraints errors.
> 
> Assume 2 classes A and B, with 1:n relation.
> We can resume sequence as this :
> 
> - open tx
> - read object A
> - read collection of object B
> {
>  - lock object B
>  - set null to reference object A in B object
> }
> - flush() (with TxExt method) (normally database FK are null now for
> database connection)
> - read collection of object B

why do you read the collection again? How do you read the collection of 
B? When using a different PB instance (outside of the running odmg-tx) 
you will not see any changes till commit.

Why don't you simply lock B, nullify the FK to A, delete B and commit or 
flush()?


> {
>   - delete B ( database.deletePersistent method)
> }
> 
> - commit tx
> 
> The troubles don't occur with DefaultObjectCacheImpl.

in the default cache you will always immediately "see" any changes of 
any object (the "dirty read" problem discussed in a previous mail)


> Hum, did i miss another way to flush database with 2LCache ?
> 
> 
> Another question ( different) :
> Is there a way to get the running transaction without no reference as
> Transaction (kind of join with the running thread) ? in the way to get the
> broker of the transaction.

Think I didn't catch the sentence. Nevertheless I will try to give an 
answer. A different thread can join a running tx using 
Transaction.join() method. To get the running tx of the current thread 
call Implementation.currentTransaction()

regards,
Armin

> 
> 
> Regards
> 

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