Yes, youre right.
Anyway, in my case it would be more appropriate to generate Tx ID's by
myself to avoid generatedUniqueTxId() problem. As first step i will
probably copy this patched method into my code and use it instead of
calling frm.generated....
Thanks for help. And sorry for bothering, this should go to the users
maillist, not dev, right?
~t~
Joerg Heinicke wrote:
Cservenak Tamas <cservenak <at> is-micro.hu> writes:
The generatedUniqueTxId() method in FileResourceManager uses
System.currentTimeMillis() to generate txId's.
On my system it causes duplicate txId generation and FRM failure. I have
4 threads accessing one FRM instance.
This simple patch adds "salt" to it, with a little overhead to solve
this problem.
Unfortunately this does not help much, it only solves your problem "under heavy
load". But if there is already another txId equal to this one (e.g. generated
externally) FRM will again fail. It can only work if inside the synchronized
block the generated txId is "preserved", e.g. by putting a final static object
PRESERVED into the map and testing for it in the startTransaction(Object) method.
This will solve almost all problems except one:
1. Thread 1: generateUniqueTxId()
2. Thread 2: startTransaction(txId) with an externally generated txId -
coincidentally equal to the above generated one
3. Thread 1: startTransaction(txId) with the generated txId
But is again a magnitude more unlikely.
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
|
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
