commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cservenak Tamas <cserve...@is-micro.hu>
Subject Re: [transaction] Duplicated TxId generation under heavy load
Date Tue, 22 Nov 2005 16:50:31 GMT
Hi,

thank you for response. Jorg already convinced me to use some external
Id generator, and not the handy built in (which was a handy solution for
fast jump-in).

My "patch" for generatedTxId will be simply moved to my code and it will
do the trick, as it solves my problem.

Thank you for help,
Tamas

Oliver Zeigermann wrote:
> To me it seems generatedUniqueTxId does exactly as advertised in
> Javadocs. Don't you agree?
>
> You simply need something different as it seems. Unique Id generators
> - that's what you need - are easy to find, even in the Jakarta Commons
> Project :)
>
> Oliver
>
> 2005/11/22, Cservenak Tamas <cservenak@is-micro.hu>:
>   
>>  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:
>> commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> commons-dev-help@jakarta.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> commons-dev-help@jakarta.apache.org
>>
>>
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>   


Mime
View raw message