So you don't get the counter until you are about to complete the transaction ..... timing issue would be the same with any other technique.
Anyway, don't want to beat a dead horse - no more from me Ross Ferris Stamina Software Visage - an Evolution in Software Development >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:owner-u2- >[EMAIL PROTECTED] On Behalf Of HENDERSON MIKE, MR >Sent: Friday, 1 July 2005 9:52 AM >To: [email protected] >Subject: RE: [U2] - Determining time sequence {Unclassified} > >Ross, > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Ross Ferris >> Sent: Friday, 1 July 2005 10:51 >> To: [email protected] >> Subject: RE: [U2] - Determining time sequence >> >> My only issue with using UUID's is the fact that they weren't DESIGNED >> for time sequencing, and you could run foul of the implementation. >> >> I just ran a quick test, fired off 4 phantoms and another screen based >> process to get 5,000 sequential ID's - they all finished in under a >> second, so 25,000+tps seems AOK ... if the item IS in contention, it >> will be in cache, so in practice I don't think this should be an >issue. > >The scenario where it does become an issue is where you have >transactions >that run for a long (relatively) time. This means that although you >have >the capacity to increment the counter quickly, you can't actually do it >because the update lock on the incrementing counter has to be held for >the >entire length of the transaction. > >I don't actually see how having the counter automagically maintained by >the DBMS would help. For example, suppose that > >Transaction "A" starts and gets counter "654321123" >Transaction "B" starts and gets counter "654321124" >Transaction "C" starts and gets counter "654321125" >Transaction "D" starts and gets counter "654321126" > >Now suppose that transaction "B" fails ... > Surely transactions "C" & "D" have to be rolled back because >they > now have the 'wrong' counter value? > >I don't see this as being any advance over the UV mechanism, except that >it's less coding at the application level. > >Regards > > >Mike > >> >> Phil was originally concerned about this being a bottleneck - my >> (limited) testing leads me to believe this will not be the >> case .... The good news is that he now has multiple alternatives to >trial. >> >> Ross Ferris >> Stamina Software >> Visage - an Evolution in Software Development >The information contained in this Internet Email message is intended >for the addressee only and may contain privileged information, but not >necessarily the official views or opinions of the New Zealand Defence Force. >If you are not the intended recipient you must not use, disclose, copy or >distribute this message or the information in it. > >If you have received this message in error, please Email or telephone >the sender immediately. >------- >u2-users mailing list >[email protected] >To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
