Ah, OK, I can see what you mean now.
I am a bit concerned about that. Lets say the implementation of the compress routine was (I am going to basically compress each name to an int as it seems logical to do it this way instead of based on the lenght of the provided name):
static int counter;
static Map <String,int> names;
String jndiName = xaResourceWrapper.getJndiName();
int xidEisName = -1;
synchronzied (names) {
xidEisName = names.get(jndiName);
if (xidEisName == null) {
xidEisName = counter++;
names.put(jndiName, xidEisName);
System.out.prinltln("For the purpose of this run JNDI name: " + jndiName + " is " + xidEisName);
}
}
//write XID out using the xidEisName instead of what was provided
A> It would be a performance hit
B> We couldn't guarantee the name was the same between runs unless we used a file instead of static Map <String,int> names which would be even more of a performance hit to write this each time we get a new datasource presented to us.
Jonathan Halliday wrote:
> for EIS name was administrator would still need to keep a mapping of EIS JNDI name to EIS "short" name
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.