Mark Little [http://community.jboss.org/people/marklittle] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632280#632280 -------------------------------------------------------------- Have you tested an performance implications of this? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632280#632280] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Mark Little [http://community.jboss.org/people/marklittle] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632474#632474 -------------------------------------------------------------- Have you run performance tests or is this on paper only? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632474#632474] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Mark Little [http://community.jboss.org/people/marklittle] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632509#632509 -------------------------------------------------------------- That'd be the place to start :) -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632509#632509] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Mark Little [http://community.jboss.org/people/marklittle] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632527#632527 -------------------------------------------------------------- Well I'm assuming there will be zero impact on performance (or maybe slightly better performance). -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632527#632527] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632529#632529 -------------------------------------------------------------- Are you really, absolutely certain that there's no other way to solve this than to assign int IDs to every node?  As I've said this is going to be a very tough sell - at least with unique names, we can generate them based on the system host name and the domain configuration.  With int IDs, the space is too small for a full identifier; it's even too small for something like a cryptographic key or hash which is at least *likely* to be distinct. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632529#632529] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Mark Little [http://community.jboss.org/people/marklittle] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632558#632558 -------------------------------------------------------------- Is it possible to play tricks with the EIS name? I suspect that N(EIS) <<< N(nodes), so maybe we can require EIS names to be maintained in a configuration file and index that by 2 bits in the bqual. OK, maybe 2 bits is too small, but you get my meaning ;) -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632558#632558] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632568#632568 -------------------------------------------------------------- To clarify, if we did knock the EIS name down to an int/short as Mark indicated was feasible. We would have the following: byte[]:64:bqual   {Uid:28:sequenceId,String:variableLength:subordinateNodeName,String:variableLength:parentNodeName,int/short:4/2:EISName} Meaning we would still need to be able to get two strings into the remaining 34/32 bytes, another reason I suggested converting the node name in the AS down to an int as that saves the space of two strings rather than just one. Plus the API for getting the EIS name is already out there and is being used (I assume). We would therefore need to get folks to change their implementation of: org.jboss.tm.XAResourceWrapper::getJndiName to return this integer key for the EIS name table (or pay the cost of looking up this String in the EIS String to int table each time and XID is created). Either approach (keying node names or keying EIS names) levies an administration overhead but for space considerations and the fact that the EIS name API is already out there I think we should use ints in the XID for nodes rather than EIS names - again though, happy to be dissuaded. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632568#632568] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632705#632705 -------------------------------------------------------------- Hi guys, I just want to prefix this answer with the statement that given unlimited data length I don't mind whether or not node names were encoded as Strings, Ints, BLOBs or GLOBs. The administration of this thing is one thing. But in terms of the XID structure it only has 64 bytes to play with in the bqual. The bqual needs the following: 1. Sequence number - we all agree with this 2. Parent node name - This is vital for recovering orphan subordinate transactions as explained above 3. Subordinate node name - This is vital for recovering orphan subordinate resources as explained above 4. EIS name - required for debug Lets say we keyed the EIS name down to an int - 4 bytes - using Jonathans suggestion and the algorithm I indicated earlier, thereby paying the performance cost of reading/writing to a dynamic EIS key file and looking up the EIS name in the key map each time. Next, the sequence number is 28 bytes because it is a Uid, we could look at trying to make this smaller but it needs to be unique within the scope of the gtrid. That leaves us 32 bytes to encode the two node names (parent and subordinate). If someone can confirm that we can have a validator on CoreEnvironmentBean that says node names that can't be .getBytes("US-ASCII").length'd down to 12 bytes or less can be "throw new CoreEnvironmentBeanException"'d is fine, I can move back to Strings for these within an hour or so (I say 12 bytes so we can write the byte[] and its length - an extra 4 bytes, to be fair we could use a short here so call it 14 bytes as the max getBytes.length of the node name). I would also need it confirming that we are fine to make the adjustment of the EIS name down to an int which is just logged to file and so admins debugging issues will need to crack open that file to reverse lookup the actual EIS name from the keys which are going to be encoded in the Xids. Tom -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632705#632705] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632736#632736 -------------------------------------------------------------- Hi Mark - sorry, I know you do!! Just setting out the issue with node names being stored uncompressed, unless they can be encoded into 14 bytes is all. If the node name can't be fit into 14 bytes as a string then it is going to need to be indexed somewhere and the only thing I can think of is the central file with node names in. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632736#632736] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632764#632764 -------------------------------------------------------------- Yeah, possibly, I wonder how much space we are going to save, but yeah, I can take a look  at that. That said, what size should we be looking at aiming for allowing node names? At the moment, it is possible that 14 bytes is enough to encode the node name? David, what should be aiming to allow size wise for a remoting node name? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632764#632764] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632770#632770 -------------------------------------------------------------- I doubt that they would have more than that too - although it would make an interesting case study :) But I also assumed that no one would have more unique nodes than would fit in a standard int either. I think the problem with encoding "node names" as numbers is that David is saying he doesn't think people will want to administer the nodes as numbers, rather he preferes a string derived from the hostname and domain (out of interest David how do you propose to deal with multiple nodes on the same machine, plus remember that for TS these node names are sticky per instance you want to recover). -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632770#632770] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632776#632776 -------------------------------------------------------------- Mark Little wrote: +1 All I want is for nodeIdentifiers to be provided to TS through the CoreEnvironmentBean as an integer and that the same recoverable instance of TS gets the same integer node name each time, I can then happily encode this in the XID and failure recovery etc proceeds as normal. What systems are used to provide that node identifier to TS should be largely a black box to me. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632776#632776] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Mark Little [http://community.jboss.org/people/marklittle] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632987#632987 -------------------------------------------------------------- Let's get a response from David before proceeding, but I continue to believe that a number is fine as long as we can provide some higher level tool to isolate users from this. BTW, if it's 27 bytes then does that mean it could (almost) be a Uid? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632987#632987] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/633034#633034 -------------------------------------------------------------- If I understand correctly, you're using integer values internally but the user doesn't have to be aware of it?  If so I'm in favor.  Can you enumerate what additional configuration items the user will require with this solution? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/633034#633034] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/633073#633073 -------------------------------------------------------------- OK, unfortunately it isn't acceptable to require the user to configure int values like this.  But... what about this idea? Basically you're looking for approximately 32 bits of uniqueness right?  Well a node name is based on host name, which is ultimately based off of DNS labels.  A DNS label can contain one of 26 letters, one of 10 digits, a "-", or a "." (but cannot start or end in "-" or ".").  This means that a single character has only 38 possible values, which means you can fit about 6 of them into 32 bits, if you squeeze really hard. Perhaps we can set it up so that we have just a couple more bits - maybe 42, which would be just enough for 8 characters - and default it to the compressed node name, and if the node name is greater than 8 characters we can print a warning and suggest that the user choose a unique 8-character name? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/633073#633073] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/633172#633172 -------------------------------------------------------------- I understand, it isn't perfect, but we do already have the requirement that our (hostname-based) node names be unique for EJB, management, clustering, etc. to function correctly.  When more than one server is started up on the same host via domain management, the node name is based on the host name plus the server name (which is unique within a server group, which is a very manageable namespace as it is centrally defined). Basically if we start up two servers with the same node name, there are a whole host of services that won't function correctly if the user makes the servers interact.  It's still a lesser burden to choose a name which can mostly be defaulted to the node name which already must be unique than to choose an integer.  Otherwise we're back to the drawing board to come up with a scheme which can use either a full name or topology information (or some other scheme, like topology + full name hash) to fill in the knowledge gap that each node needs for recovery.  Using a plain int simply is not an option. As for the non-roman alphabet-based names, they encode back to the same character set as any other domain name, so we don't really need any special handling for this case as we can perform the same encoding.  It would be noted however that such names would have a significantly reduced maximum length, potentially as few as 2 or 3 characters. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/633172#633172] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/633314#633314 -------------------------------------------------------------- I should point out that the impact of moving from static subordinate node identifiers to dynamic ones is that an extra log write/delete per transaction is required, which will clearly have an impact on performance. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/633314#633314] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/633347#633347 -------------------------------------------------------------- Hi Mike, Hopefully my previous answer helps to clarify some of the motivations for the current writes. It should also be pointed out that I don't mandate how this data is persisted, indeed potentially there are some items that the transport must store which can be persisted using TS optimised logging mechanisms, that is left to the transport to determine. Thinking about your suggestion, one example where TS logging could possibly help to optimize this is the dynamic subordinate node identifier. As this Xid is for one of our own transactions, potentially David could provide his own XidImple implementation which packs the static subordinate node and its parents node identifier name after the bqual (which would be String node identifier instead of using a transport allocated dynamic int as I was describing earlier) in as an extra attributes to be persisted. Although it is likely that doing so would require work throughout the code base to ensure it was feasible to allow. Also, for example, I assume the JDBC action store assumes a schema that can take a BLOB(128) for the data part of an XidImple we would therefore need to determine which objectstores this would work with. NOTE: This is a sponateous response to your point, I am not entirely certain it would work! If you didn't go down that route (or it is proved not to work) then the issue you have is the transport needs to persist items at a different time to that which the transaction service current does. As Jonathan has pointed out, the transaction service is heavily optimized in this regard and with the particular set of requirements in hand, it seems that we have to add a few of these persistence points back (well the transport adds them, specific for this feature). I will think more about providing a bespoke XidImple that packs in more data than a Xid typically allows - thanks for the suggestion :) -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/633347#633347] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Mark Little [http://community.jboss.org/people/marklittle] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/633485#633485 -------------------------------------------------------------- This concerns me greatly. We've spent years optimising TS. Presumed abort semantics help here obviously, but there's been a lot of other work. Let's not negate that! -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/633485#633485] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/634251#634251 -------------------------------------------------------------- Just to confirm, the work related to compressing the EIS name down to an int by storing a mapping file is actually done and in the branch as it is work not strictly related to XID changes for distributed JTA but is a functional requirement so it made sense to get it in the next release. Therefore, when I get back from paternity the following changes may be made: 1. We can get rid of the requirement for the transport to maintain the subordinate node name as a dynamic integer as there is now enough space in the bqual to put the node name as a string (assuming 64(bqual length) - 28(Uid) - 4(eis key)) 32 bytes is enough to store a remoting name. Of course, if we ever need to put something else in the bqual that will not be possible again. 2. I can see a place where it would be relatively straighforward to add the parents parent node identifier (jca.SubordinateAtomicAction). I will probably create a different class for this (distributedjta.SubordinateAtomicAction), this gets rid ofone of the other persistence points of the transport. Both of these changes appear relatively trivial to make again but I wont destabilise branch before I leave (hopefully I wont destabilise it on return either). I believe the transport will still need the initial persistence point, that is it needs to know (for outstanding transactions) which servers it has talked to so that it can call recover on them in the case of failure. This is optional and we can rely on timeout typically, unless timeout is not set... -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/634251#634251] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/633431#633431 -------------------------------------------------------------- Hi David, Sorry the example doesn't map directly to your use case, I condensed it from the test suite and it is really more guidance on what tasks are required from the transport so hopefully it has proved at least useful in that regard. Indeed as a talking point for questions at least it seems to have helped :) NOTE: My answers are below but they are caveated by the statement that they are broadly based on the current approach. Here is the answer to these questions: Interesting suggestion! It is indeed possible that for this type of XA resource we could look at creating a bespoke XID with the format: XID { int:formatId byte[]:gtrid { UID:sequence, String:nodeName } byte[]:bqual {String:subordinateNodeName, String:parentNodeName } } We know we can do that because we know that there is only going to be (by convention) a single proxy to the remote server for this node, therefore the branch is unique without the Uid. TS is not really geared up to support generating XIDs differently per XA resource, but we can probably change that! Not to say we shouldn't do that, but I was thinking about this (well a close derivative of it, based on ints again sorry - but in my mind they are both tokens) over night though, there is still an issue with storing the node identifiers in the XID which the transport has to work around by persisting them. Basically, if you did what you are saying (which is a neat idea). The proxy XA resource would be enlisted with the ID (assuming nodes named 1,2,3 etc - Strings though): ProxyXAResource - bqual{"2","1"} Remote subordinate transaction  - bqual{"3", "2"} That means in recovery you can't ask the remote server for a list of XIDs it knows about because it will return {"3","2"} but the local server doesn't know about 3,2, in this scenario it knows about 2,1. Also, "normal" XIDs would need to be able to fit a String subordinate node name in them (for orphan detection). Meaning that we would definitely need to make space for a normal bqual: byte[]:bqual {UID:sequence, String:EISname} As Jonathan suggested we can basically do this by changing EISname to be an int leading to: byte[]:bqual {UID:sequence, String:subordinatenodename, int:EISnameKey} In terms of these questions: 1. It shouldn't really impact things, except to say that access to *obtaining a reference or creating a new instance* on the subordinate transaction should be synchronized (in the example this is getAndResumeTransaction). This use case does add further legitimacy to registering the proxy *after* you return from the remote call. Jonathan may have a different perspective on this though? But as I understood it multiple threads accessing the same transaction is fine in JBoss TS. 2. Yes you are broadly correct, I do actually demonstrate this in the example. Take a look at the operations (and usages of) LocalServer::storeRootTransaction LocalServer::removeRootTransaction and LocalServer::getAndResumeTransaction. 3.There are two things that need persisting, one is the information you indicated, you can see that this must be done in two places, once when you talk to the remote server (before enlisting an actual proxy) and once again when the proxy is enlisted and you have a real Xid - if we did use your approach above we would only need to do this once as we can calculate the proxies XID before it is actually enlisted. In the example this is done when the proxy is created (ServerImpl::generateProxyXAResource) and updated when the proxy is enlisted (I delayed it to ProxyXAResource::prepare, this is the persist that could be elimated). That covers your point 3 above, but you also need to persist the dynamic subordinate node identifier at the moment. Based on the discussions so far, the most appropriate changes would appear to be to the XID, to make special ones for proxy resources and to key EIS names as int so we have room for subordinate names for normal Xids. Making these changes would: 1. Impact existing users from a usability perspective that are already using the EIS name and expecting to read this from the persisted Xid somehow. 2. Require investigation to determine if customizing bqual for a particular type of resource (saying implementing a ProxyXAResource interface or similar) was even possible 3. Still require the transport to make an additional log write per transaction the list of servers it talks to in order to recover transactions at them. That said, I am due to go on paternity any time now for two weeks so would be reluctant to alter the code too much further now (e.g. keying the EIS name or bespoke XID creation) but I can certainly investigate both of those in a branch. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/633431#633431] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/633487#633487 -------------------------------------------------------------- Thanks for the clarification, and as for leaving this alone till after paternity, I am very much happy to! (breathes sigh of relief). Although the required TS code changes have been fairly minor thus far, working through all the error conditions is quite an adventure and has led to an extensive test harness being developed to ensure TS supports access in this specific manner. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/633487#633487] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632578#632578 -------------------------------------------------------------- Just to be clear, I am still not sold on the idea of touching EIS name as the API is "in the wild". That said, and terminology aside, what we need is some way to know at which entity an XID was generated so that the recovery manager can detect it is an orphan. I have been calling these node names, as the exisiting terminology is "nodeIdentifier". Remember though, these are transaction manager "nodes", not nodes as in hosts. Potentially there can be more than one transaction manager node per host and each of these will need to be given a unique persistent identifier. This is an existing and established requirement of JBoss TS. I am not sure if I am misintrepetting Mark or David here but I think Mark was suggesting putting the EIS name to EIS XID key into a configuration file so that we can then fit in the node name as a String as David would like. I was saying that is not great as either the established API needs to change to pass us the key or we take a performance hit of resolving the key in the configuraiton file. Plus at the moment we are preferably going to put two node identifiers in the bqual. In either scenario, the administrator is going to need to keep a mapping file. Either remoting node identifier to transaction manager node name (my preference) or EIS name to EIS int key. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632578#632578] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632584#632584 -------------------------------------------------------------- I can see wanting the node name for debugging purposes in the gtid (for the originator) and bqual (for the branch node).  We'd have to make sure that we truncate names which are too long though as the limit for node names is currenty 255 characters (though we could reduce it further, as the maximum length of a host name label is 63 (recommended maximum length is 24)). But what I'm not clear on is, why exactly do we need the other node names in the XID?  I think that come out of off-forum discussions and without that information I can't really offer up any ideas.  It seems like we should be able to take advantage of the unique topography of this scheme to provide some of the information. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632584#632584] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632594#632594 -------------------------------------------------------------- Okay so here's where my confusion came in. When I suggested that sequence idea, the thought was that root node + sequence is basically equivalent to (subordinate node name + parent node name) in that any participant should be able to tell whether a branch belonged to it or its descendants, and also should be adequate for filtering recovered XIDs.  But I'm not sure what you mean by "orphans" exactly - aren't all branches normally recovered by the root?  If so, does the subordinate path actually matter? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632594#632594] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632606#632606 -------------------------------------------------------------- Ideally the transactions would be recovered by the root TM. But you can have failure scenarios which orphan a subordinate. HOWTO orphan a subordinate We only write out information about a transaction after the prepare phase. Proxy cascades the prepare to the subordinate --- Crash at root node --- You now have an orphan! -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632606#632606] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632632#632632 -------------------------------------------------------------- Hi David, No, its not quite that, that scenario you describe does exist, but thats not the scenario termed an orphan in this case. An orphan is where a remote resource has a record of the transaction but the remote transaction doesn't. Sequence: 1. Enlist resources at TM1 2. Propagate to TM2 3. Enlist resources at TM2 4. Return control to TM1 5. Call commit at TM1 6. Proxy the commit to TM2 7. Prepare the resources at TM2 8. -- CRAAAASH AT TM2 -- Now, when TM2 recovers it wont have any record of the transaction at TM2 so the prepared resources at TM2 are orphaned forever. Hence TM2 needs to be able to be able to detect these orphans and roll them back (presumed abort). Tom -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632632#632632] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632656#632656 -------------------------------------------------------------- Not being able to sleep, I was thinking about the following. Another way an orphan can be left (this time a subordinate transaction rather than a subordinate transactions resource) is: 1. Start transaction at TM1 2. Propagate to TM2 3. Enlist the database at TM2 3. Return to TM1 but before the proxy resource can be enlisted at TM1.... 4. -- CRASH -- This scenario has a couple of issues salient to us. 1. The transport is going to need to keep a record *before it talks to the remote server* of all remote servers it talks to so that it can generate proxy XAResourceRecoveries to make sure when the server housing it crashed it did not leave any transactions in flight. 2. The case provides the absolute requirement of storing the parents node name in an Xid as during recovery this is the only information we have to help identify which subordinate transactions in flight are owned by a recovering parent -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632656#632656] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Jonathan Halliday [http://community.jboss.org/people/jhalliday] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632588#632588 -------------------------------------------------------------- No, the server can simply allocate and store a new uniq short EIS name for any long name it has not seen before. Because the server has view over the entire scope, so that mapping process can be automated.  That's the key difference with nodeIdentifier - a server does not have sufficient local information to allocate itself a globally uniq node id. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632588#632588] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632591#632591 -------------------------------------------------------------- -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632591#632591] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion "Re: Remote txinflow: XID changes" To view the discussion, visit: http://community.jboss.org/message/632597#632597 -------------------------------------------------------------- Ah, you're just looking at it from the opposite end; however the point still stands that the EIS name is equal to the node name.  If I set up a Remoting connection into the EJB client, the node (and cluster) name of the remote side is noted for various purposes.  This also has the advantage that a node can be contacted via a different configuration, socket, or protocol and still be recognized which allows us to port over UserTransaction as well as stateful EJBs to new connections.  It should also help us with this issue. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/632597#632597] Start a new discussion in JBoss Transactions Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]