commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Zeigermann <oliver.zeigerm...@gmail.com>
Subject Re: [transaction] Duplicate TX id's
Date Mon, 23 May 2005 17:53:35 GMT
On 5/23/05, David J. M. Karlsen <david@davidkarlsen.com> wrote:
> Oliver Zeigermann wrote:
> > On 5/21/05, David J. M. Karlsen <david@davidkarlsen.com> 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.
 
> >>you can apply my patch.
> >>It uses doomdark.org 's UUIDGenerator. (the site is down at the moment).
> >
> >
> > I would prefer if you simply generated your ids using this generator
> > without changing the file resource manager code for two reasons:
> that's what I'm doing in my app. (Providing the ID's myself, and not
> calling generateUniqueID).
> 
> >
> > (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. 

> > (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?

Still not convinced ;)

Oliver

---------------------------------------------------------------------
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