commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David J. M. Karlsen" <da...@davidkarlsen.com>
Subject Re: [transaction] Duplicate TX id's
Date Tue, 24 May 2005 01:35:26 GMT
Oliver Zeigermann wrote:

>>>>Hmm, yeah, but still - I cannot see why txId should be unique, the code is:
>>>>
>>>>public String generatedUniqueTxId() throws ResourceManagerSystemException
{
>>>>       assureRMReady();
>>>>       String txId;
>>>>       synchronized (globalTransactions) {
>>>>           do {
>>>>               txId = Long.toHexString(System.currentTimeMillis);
>>>>               // XXX busy loop
>>>>           } while (getContext(txId) != null);
>>>>       }
>>>>       return txId;
>>>>   }
>>>>
>>>>        
>>>>
>>>It will if you actually use the id to start a new transaction. In this
>>>case getContext(txId)  will not return null and the procedure will be
>>>repeated.
>>>      
>>>
>>It only ensures that you are not given a txId *in use* (eg. started).
>>Several equal txId maybe produced by this method - and worse - you will
>>only discover this when you try to start the supposedly unique TX. Thus,
>>it is broken... It should, as the name implies, generate truly unique id's.
>>    
>>
>
>I disagree. The name implies that it generates a truly unique *tx* id,
>i.e. a tx id not currently used by any transaction which it does.
>  
>
That may be so - but don't you think it's more practical to get a really 
unique UUID (which still is guaranteed not to be in use) - opposed to 
getting a id which *may* be unique (and still guaranteed to not be in use).
Which means the tx is rolled back - you have to catch the exception - 
parse the string, find that it wasn't unique and generating another one 
- and hoping for it not to be in use? It would be possible to return the 
same string each time (an extreme case/example) - it would still be 
unique - but only the one txId could be running at any point in time. 
(effectively making transactions redundant :-)) I think so, so I don't 
use the one from the API (as it very often collides with one already in 
use) - but have to provide them myself.

>(1) The above code is not broken
>  
>
>>I beg to differ.
>>
>>    
>>
>>>(2) Changing the code would introduce a new dependency to another lib
>>>      
>>>
>>True, that is bad. I'll put the generator code into another method that
>>we may call. OK?
>>    
>>
>
>Depends on the original license of the code. 
>  
>
Yeah - maybe we could pull out parts of commons ID until it is out of 
the sandbox?

>>>(3) The lib's licencse is unclear to me
>>>      
>>>
>>I saw it included in some sandbox jakarta code - but that does not
>>neccessarily mean the license is OK.
>>    
>>
>I could not even check what license it has. Which on is it?
>  
>
It's used here: 
http://ws.apache.org/ws-fx/addressing/xref/org/apache/ws/addressing/uuid/JugUUIdGenerator.html
But if we should depend on anything - commons ID would be the right 
thing (TM) - but it's still in the sandbox.


>Still not convinced ;)
>  
>
:-) I understand the licencing and depdendency issues - but still, I 
truly belive generateUniqeTXID should return a truly random ID - and I 
would guess that almost every transaction manager made would work that way.

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


Mime
View raw message