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