For the above mentioned case, Is there a way to make the com.arjuna.ArjunaOTS.ManagedSynchronizationPOA._invoke run in the user/application thread that commited the transaction. This might be an optimization for the case where the client invocation came from a local thread.
The threading model depends on the ORB implementation, some of which do optimize out the thread switch. However, running in the loader context of the commit()/rollback() caller is probably wrong, not least because it still leaves you in a mess if the caller is remote or is itself isolated e.g. the tx is begun/ended by the container or another app.
IMO you are better off using the loader that was in effect at the time the Synchronization was registered with the tx i.e. have the SynchronizaitonImple (JBossTS) or javax.transaction.Synchronization impl (Hibernate) keep a CL ref in the constructor and use it in before/afterCompletion. That way it still works even if the tx spans multiple isolated loaders, each of which may register Synchronizations.
Impl detail if we decide to do this on the TS side: com.arjuna.ArjunaOTS code is autogenerated from the IDL, so don't mess with it. SynchronizationImple is where the action is.
The issue here imo is in org.hibernate.type.SerializableToBlobType.deepCopy. Brian, not sure if you remember but we made some changes to the Hibermate Type implementations that dealt with serialization such that we use the class loader of the serializable class when doing the deserialization or deep copy. Not all use cases have been covered yet. Here, the class used to determine the classloader is java.io.Serializable itself
This is changing in 3.6 and I could *potentially* back-port the changes to 3.5. Which version are you using here?