Francois Orsini wrote: <snip/>
Due to the requirement of supporting a different version of the derby client and server in the same JVM, it's not like there are a lot of other and simpler alternatives out there indeed...Am guessing we're not going to support the loading of 2 different DerbyClient versions in the same JVM...(although one could envision db2jcc.jar and DerbyClient.jar running in the same JVM...we should not be seeing any conflict if the package structure is different)
I see no reason why we should not support that assuming the infrastructure allows them to be loaded into different classloaders. For example, each could be packaged inside a different RAR file and deployed to an application server. A use case for this is different applications talking to different databases.
Similarly I think we should also allow multiple versions of the engine to be loaded as well (although not accessing the same data files). Support for this though requires evolution away from the reliance on system properties.
The use case here is isolation between the engines - for example, if an application server is being used to host applications from different organizations.
-- Jeremy
