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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
