Josh Micich wrote: > > Hello Rob, > > So you might be stuck with leaving the JVM permanently loaded. This > may not be such a bad thing if you application is multi-threaded and > has the potential for concurrent calls to POI. Multi-threading would > be harder to support assuming short-lived JVMs. > > cheers, > Josh >
Leaving the JVM loaded is fine so long as my 'print to excel' library is the only thing that uses Java in the app. But if the calling app wanted to use Java itself, there'd be a conflict. At very least, it'd want to start up a JVM with a different classpath than I use, since I've got my code and poi in .jar files that make up my classpath. My app's structured Apache-like as a transaction processing system with a pool of shared processes as opposed to a single multi-threaded process. The second time a user goes to create an XLS, they may be running in a different process than the first time, so having the JVM preloaded is less of a benefit and more of an overhead. I think it'd be better to just exit my process after creating the XLS and let the system dispatcher launch a new copy as needed. Luckily, I have that option, but it's pretty incredible that Sun's had this DestroyJavaVM thing in their documentation all along and still haven't implemented it properly. Does anybody know how Apache Tomcat deals with this? Presumably it's got a pool of processes that need to run different Java code on different invocations. I guess if they all use the same classpath, then the same JVM could service them all. Is that the trick? Rob -- View this message in context: http://www.nabble.com/Using-POI-via-JNI-tp20774758p20794395.html Sent from the POI - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
