I probably wont be able to look at this in detail for at least several days. Could you please
1. look at the transaction logging in jboss 4 to see if that looks like a better long-term solution: if I understand the problem you are having the logging should also solve it. I __might__ backport this to 3.2 but almost certainly not to 3.0.x 2. indicate which version(s) of jboss your patch is for. 3. file either a bug report or a patch on sourceforge and assign it to me if possible. Otherwise I am very apt to lose track of this. Thanks david jencks On 2003.01.05 14:28:58 -0500 Jamie Burns wrote: > David J, > > back in October we were dialoging about XidFactory and a transaction id > problem that could occur if MS SQL Server is not restarted when JBoss is > stopped and started. The problem was traced to the XidFactory using the > same baseGlobalId and resetting its globalIdNumber to zero each time it > is started. > > Ive made some changes to JBossXidFactory based on our discussion. > > At the time you asked about looking into a guid that is used in other > parts of JBoss as a solution to creating a unique baseGlobalId each time > JBoss is started. The org.jboss.util.id package has a GUID class that > creates unique ids based on the host address, time stamps and counters. > The guid it creates is around 40 characters long and will be unique even > for multiple instances of JBoss on the same physical machine. > > I wasnt sure if you still wanted to keep the hostname in baseGlobalId. > Ive kept it in but, its likely it will be truncated alot of the time > because of the size of the GUID. > > The JBossXidFactory sticks to reserving 14 characters for the > globalIdNumber. The setter method for baseGlobalId doesnt enforce this. > Ive added code to truncate the value passed to the setter if it is too > long. Im not sure if this is the best approach though. Truncating the > value may remove enough significant characters from the string that it is > no longer unique. Maybe it would be better to throw some exception if > the baseGlobalId was set to a string that doesnt leave 14 characters for > the globalIdNumber. What is your view on this? > > In the old XidFactory you had a setter method for the globalIdNumber. You > dont have this in JBossXidFactory so the next comment isnt very relevant, > but l'll make it to be thorough. The globalIdNumber is a long which can > be up to 22 digits. My thought with the old XidFactory was that someone > could supply a globalIdNumber that was greater than 14 digits. If you put > a setter method for globalIdNumber back into JBossXidFactory or if you > get more than 10^14 transactions taking place in the lifetime of a JBoss > instance (pretty unlikely l guess) you will have the potential for > non-unique transaction ids. > > One last thing - again to be thorough. The GUID uses the system time a > few times to create its unique string. The system time on MS Windows is > only accurate to the nearest 10-15 milliseconds. Someone would be pretty > unlucky to get two GUIDs that are the same, but it is possible on a > Windows machine if they are created within 10-15 ms of each other. If it > does happen to someone maybe they will find this posting. I cant see a > way to get a 100% guarantee of uniqueness. > > Ive attached JBossXidFactory with the changes lve made. > > Let me know if you need anything done. > > Jamie > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> > <HTML><HEAD> > <META http-equiv=Content-Type content="text/html; charset=iso-8859-1"> > <META content="MSHTML 6.00.2600.0" name=GENERATOR> > <STYLE></STYLE> > </HEAD> > <BODY bgColor=#ffffff> > <DIV><FONT face=Arial size=2>David J,</FONT></DIV> > <DIV><FONT face=Arial size=2></FONT> </DIV> > <DIV><FONT face=Arial size=2>back in October we were dialoging about > XidFactory > and a transaction id problem that could occur if MS SQL Server is not > restarted > when JBoss is stopped and started. The problem was traced to the > XidFactory > using the same baseGlobalId and resetting its globalIdNumber to zero each > time > it is started.</FONT></DIV> > <DIV><FONT face=Arial size=2></FONT> </DIV> > <DIV><FONT face=Arial size=2>Ive made some changes to JBossXidFactory > based on > our discussion.</FONT></DIV> > <DIV><FONT face=Arial size=2></FONT> </DIV> > <DIV><FONT face=Arial size=2>At the time you asked about looking into a > guid > that is used in other parts of JBoss as a solution to creating a unique > baseGlobalId each time JBoss is started. The org.jboss.util.id package > has a > GUID class that creates unique ids based on the host address, time stamps > and > counters. The guid it creates is around 40 characters long and will be > unique > even for multiple instances of JBoss on the same physical > machine.</FONT></DIV> > <DIV><FONT face=Arial size=2></FONT> </DIV> > <DIV><FONT face=Arial size=2>I wasnt sure if you still wanted to keep the > > hostname in baseGlobalId. Ive kept it in but, its likely it will be > truncated > alot of the time because of the size of the GUID.</FONT></DIV> > <DIV><FONT face=Arial size=2></FONT> </DIV> > <DIV><FONT face=Arial size=2>The JBossXidFactory sticks to reserving 14 > characters for the globalIdNumber. The setter method for baseGlobalId > doesnt > enforce this. Ive added code to truncate the value passed to the setter > if it is > too long. Im not sure if this is the best approach though. Truncating the > value > may remove enough significant characters from the string that it is no > longer > unique. Maybe it would be better to throw some exception if</FONT></DIV> > <DIV><FONT face=Arial size=2>the baseGlobalId was set to a string that > doesnt > leave 14 characters for the globalIdNumber. </FONT><FONT face=Arial > size=2>What > is your view on this?</FONT></DIV> > <DIV><FONT face=Arial size=2></FONT> </DIV> > <DIV><FONT face=Arial size=2>In the old XidFactory you had a setter > method for > the globalIdNumber. You dont have this in JBossXidFactory so the > next comment isnt very relevant, but l'll make it to be thorough. > The > globalIdNumber is a long which can be up to 22 digits. My thought with > the old > XidFactory was that someone could supply a globalIdNumber that was > greater than > 14 digits. If you put a setter method for globalIdNumber back into > JBossXidFactory or if you get more than 10^14 transactions taking place > in the > lifetime of a JBoss instance (pretty unlikely l guess) you will have the > potential for non-unique transaction ids.</FONT></DIV> > <DIV><FONT face=Arial size=2></FONT> </DIV> > <DIV><FONT face=Arial size=2>One last thing - again to be thorough. The > GUID > uses the system time a few times to create its unique string. The system > time on > MS Windows is only accurate to the nearest 10-15 milliseconds. Someone > would be > pretty unlucky to get two GUIDs that are the same, but it is possible on > a > Windows machine if they are created within 10-15 ms of each other. If it > does > happen to someone maybe they will find this posting. I cant see a way to > get a > 100% guarantee of uniqueness.</FONT></DIV> > <DIV><FONT face=Arial size=2></FONT> </DIV> > <DIV><FONT face=Arial size=2>Ive attached JBossXidFactory with the > changes lve > made.</FONT></DIV> > <DIV> </DIV> > <DIV><FONT face=Arial size=2>Let me know if you need > anything done.</FONT></DIV> > <DIV> </DIV> > <DIV><FONT face=Arial size=2>Jamie</FONT> </DIV></BODY></HTML> > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
