I have several architectural comments. *Use GUIDs *
Session ID collisions may cause all sorts of problems. Perhaps, it makes sense to use globally unique identifiers? GUIDs are 16 bytes long. *Global TransactionId (either global scope or transaction domain scope)* Global transaction id implies that there is a global transaction manager somewhere capable of committing or aborting distributed global transactions. Thus, global transaction IDs have to be generated by such global transaction manager or registered with it and have a meaning only in the context of such global transaction manager. As transactions can be nested, it may make sense to consider nesting global transaction managers. What may be transaction manager discovery mechanism and how do you encode all this information in global transaction IDs? *Session ID (probably, global scope) + Task ID (session scope)* I agree with Baron. I would like to suggest using Task ID field in addition to Session ID. Task ID would give total freedom to multitask, parallelize, delegate, "map", etc. Session ID is absolutely needed for session affinity and session failover implementation. *What Else?* Modern TCP/IP transport layer protocols provide reliable connection setup, connection teardown, explicit congestion notification, congestion control, and feature negotiation. So far, everything discussed here assumes TCP transport, because TCP is what MySQL uses and what is supported in the Amazon EC2. However, Open Cloud Consorsuim is promoting UDT. There is also wide support for SCTP and DCCP. I expect wide UDT adoption in the cloud. I would argue that it makes sense to have such fields in the protocol that will allow for easy protocol translation and multi-ptotocol deployments. SessionID is most definitely a must have field from this standpoint. My two cents... Regards, Alex Esterkin On Fri, May 1, 2009 at 7:49 AM, Mark Leith <[email protected]> wrote: > > On 1 May 2009, at 04:05, Baron Schwartz wrote: > > Suggestion: consider including the session ID in every packet back and > forth to the server. > > Reason: it makes it much easier to do things with the traffic. > Consider my use case -- observing traffic. If I haven't been watching > since the beginning, I don't know what session ID I'm looking at. > > Other use cases might exist, such as the ability to join an existing > session, and thereby have multiple connections sharing a transaction. > Or just debugging. > > Drawback: an extra 4 bytes per packet? > > > > Having the global transaction id on the wire could be pretty helpful too. > :) > > Cheers, > > Mark > > -- > Mark Leith > MySQL Regional Support Manager, Americas > Sun Microsystems, Inc., http://www.sun.com/mysql/ > > > > > > _______________________________________________ > Mailing list: > https://launchpad.net/~drizzle-discuss<https://launchpad.net/%7Edrizzle-discuss> > Post to : [email protected] > Unsubscribe : > https://launchpad.net/~drizzle-discuss<https://launchpad.net/%7Edrizzle-discuss> > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
