> -----Original Message-----
> From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, January 16, 2001 11:15 PM
> To: [EMAIL PROTECTED]
> Subject: tomcat contexts and JVMs
>
> Hi All:
>
> I am a bit confused. Does each context in server.xml have its own JVM
> session?
>
> For example, I have two contexts:
> 1) Catalog - for a product catalog app
> 2) Support - for customer support apps
>
> Both these contexts need a connection pool to my backend Oracle database.
> If both contexts use separate JVM sessions then I would have double the
> number of connections to my Oracle database and the connections would
> increase per context added.
>
> Is there a way to share the connection pool object across contexts? Again
> all this relates back to whether the various contexts runs within one JVM
> session or each has its own JVM session.
[Kitching Simon]
I'm not quite sure what you mean by "session". Presuming you
mean a "separate jvm process", the answer is no. All contexts
in tomcat run in a single tomcat instance, unless you start messing
about with load distribution features to deliberately run multiple
jvms.
However, the sun servlet spec essentially states that each context
should *look like* it is running in a separate jvm; this is done by
careful use of ClassLoaders. The whole design of the sun servlet
spec points towards web applications running totally separated
from each other, so that *if* you decide to move a web application
to a separate jvm or even separate machine, nothing breaks.
As far as I know, you can only share data between contexts by
deliberately violating the servlet specifications, which means that
it is also a very non-portable solution.
I suggest
(a) run your Catalog and Support stuff together within a single
context.
(b) use a single EJB server which does the actual database access,
and call this EJB server from your web applications.
(c) just live with the extra number of connections.
All the above is just my interpretation of the specs : no
guaruntees I've understood it right :) - any corrections from
those who know better are welcome.
Regards,
Simon
> Thanks,
>
> Joshua
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
