-
1. Re: Generating unique transaction ids
adrian.brock Nov 18, 2005 2:14 PM (in response to timfox)"timfox" wrote:
Cons of using a guid is that it takes up more space in db, plus look ups into index are probably slower.
No the main issue is maintaining the index (writes) not the lookup, although this depends
upon the quality of the db implementation. ;-)
There is an outstanding issue to in JBossMQ to create a JMS_DESTINATIONS
table with integer->destination string (write through cached in memory)
to improve the index and disk space usage. -
2. Re: Generating unique transaction ids
adrian.brock Nov 18, 2005 2:16 PM (in response to timfox)You really want to use the internal db sequence generator
with fallback to GUID where it isn't supported. -
3. Re: Generating unique transaction ids
adrian.brock Nov 18, 2005 2:20 PM (in response to timfox)Questions:
Who does the recovery if multiple nodes are using the same "transaction log"?
How does a new node do the merge? The transaction log is a record of prepared/committed
changes not the current state as seen by ongoing uncommitted operations on other nodes.
e.g. delivery is not transactional, only acknowledgement. -
4. Re: Generating unique transaction ids
timfox Nov 21, 2005 9:35 AM (in response to timfox)The whole question of how we recover queues/durable subscriptions and let them join/leave in a clustered environment is an interesting one.
I believe Ovidiu is working on this as we speak. I am certainly curious as to how this is done.
Currently the transactional state is isolated from the "comitted" state by using a column"STATE" (basically same as TXOP in jboss mq)
One other thought; if we're going to have seamless failover I think we also need to replicate the global-local transaction map (TransactionRepository) between nodes.