"mark.little(a)jboss.com" wrote : "reverbel" wrote : "mark.little(a)jboss.com" wrote : "reverbel" wrote : | | | | Instead of embedding a full Xid into, say, the object id part of an IOR, the OTS/DTM code uses a long (the local transaction id) as the CORBA object id. Besides reducing wire traffic and marshalling overhead, this approach reduces logging overhead, as it reduces the size of transaction log records that contain Resource or Coordinator references. | | | | | | | | | | I will just say that the problems with storing anything that isn't guaranteed to be globally unique are fairly obvious and risky where transaction processing is concerned. | | | | Not sure what was your point here... Resource and Coordinator references are globally unique, as each such reference contains endpoint info such as host and port, plus a local id field that is unique within that endpoint. Usage of "really local" ids (rather than using full Xids as local id values) avoids nesting of globally unique identifiers, which would be a wasteful thing to do. | | | | Regards, | | | | Francisco | | But if these longs or integers are being stored with the log as a reference to a Resource/Coordinator/Xid, then eventually your identifier will wrap. This means that it's possible for the same id to be used to key into different Resource/Coordinator/Xids at the same time. In practical terms, this is not possible if local transaction ids are 64-bit longs. Even with a sustained transaction rate of one million TPS (one transaction per microsecond!), it would take more than five hundred thousand years (!!) for a 64-bit transaction counter to wrap: 60 seconds/min * 60 mins/hr * 24 hrs/day * 365 days/year = 31536000 seconds/year 2^64 transactions/wrap * 10^-6 seconds/transaction * 31536000 seconds/year = 584942.41 years/wrap Regards, Francisco View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976990#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...