configuration identifier issues

["Mark Little" <mark.little@arjuna.com>]

Issues 61 and 62 are about configuration identifiers, and I have to admit that when I saw them I had to go and jog my memory about what role the configuration identifier played in the specs! The idea has always been that a given context service may be managing different configurations of ALS-es. So, for example, one configuration may be transactions + security, whereas another may be transactions + replication, or replication + security (you get the idea). When invoking operations on the context service (e.g., begin) it's necessary to identify which assembly of ALS-es you want, and that was the role of the configuration identifier.

 

Now it seems to me with the benefit of hindsight, that this is actually an addressing issue. From a model perspective we could think of there being a separate context service for every ALS configuration. How that model is actually implemented is a separate issue (and some might say that it's even implementation specific). In some ways it's the same as having a different transaction coordinator endpoint for every single transaction that is created, rather than allowing the same endpoint to multplex across different transaction instances.

 

This may be an issue that has to have more discussion at the face-to-face, but I'd like to see if we can resolve this through the addressing work that Greg has already started, rather than as a separate field on each context operation.

 

Mark.

 

----
Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.
 
www.arjuna.com