"mark.little(a)jboss.com" wrote : Oh, and I assume you have to durably record the mapping between the short-hand notation (long) and the real transaction id. Essentially keep a reference as to where your index (the long) has reached so that, upon failure and recovery, you can continue counting from where you left off (or you risk generating a new mapping using the same counter before half a million years is up ;-). This durable recording is going to impose some overhead: every time you increment the counter you have to record it to disk . Plus, it probably needs to be managed transactionally too. Or did I miss something? Very good points. Generating local ids with a linear, one-dimensional transaction counter would have these problems indeed. Fortunately, a high/low approach works well here. Below I describe the one implemented by the old TM code in JBoss AS. (That part of the code is not actually old, BTW. It was written about one year ago). Split the 64-bit counter in two parts: a high part with (say) 20 bits, and a low part with 44 bits. Whenever you need to generate a new local transaction id, you increment just the low part, without durably recording its value. Whenever the TM (re)starts, you increment the high part and durably record its new value. Thus the (durable) high part counts TM restarts and the (non-durable) low part counts transactions in a TM run. With this solution, the overhead per transaction is just the cost of an in-memory increment. The downside, of course, is a significant reduction on the maximum time any given transaction may exist in the current set of transaction log files, but half a million years was too much anyway. :-) Regards, Francisco View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977076#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...