This seems a good idea. Would it be possible to reload this class without trashing the whole Tomcat?

I don't think so... At least, I cannot imagine how it would be done.

I have just come across another possibility:

Store the singleton instance in the system properties.

What do you think of this? Is it calling for trouble?


Antonio Fiol (This time w/o certificate)


Filip Hanik wrote:


I have not followed this thread,
but putting the class in common/lib or shared/lib should make it a singleton
across contexts

Filip



-----Original Message-----
From: Antonio Fiol Bonn�n [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 15, 2003 10:52 AM
To: Tomcat Users List
Subject: Re: Singleton across multiple contexts






- Extract the component into a separate JVM, and connect to it


via socket.


This is what I'd do, but I'd also write a client class to get access. I
suppose you could use RMI or something, but I'm not familiar with that.
Whatever you're comfortable with, I guess.

You could also spin off this class in it's own thread inside one of your
classloaders. That way it would shutdown and start up with the server
(or maybe that's a drawback...) and you wouldn't have to add the
overhead of another VM.



In fact, it *is* a thread. It starts and stops with the server.
Everything was really beautiful until I had to split my app in four
contexts.

What I dislike is having to go out of the app to do app-internal calls.
RMI, socket, CORBA, HTTP, ... I don't mind: I just dislike the idea.



- Extract the component into another context, and connect to it


via HTTP.




yuck.


This isn't for locking or something is it?




Nope. ;-)



I get the feeling you're
trying to use a class for storing or accessing something the way most
people use a database...



I do have a database. Databases are supposed to store data,
aren't they? ;-)

Now seriously... My application includes a web interface to a "kind of"
workflow system.

This component is the "workflow engine", which is in charge for
automatic (background) state changes and actions. When my
business/persistence logic changes a state, new potential tasks for this
"engine" arise. So it has to be notified (=called) from any context that
may change a state.





On Sun, 2003-06-15 at 08:21, Antonio Fiol Bonn�n wrote:




Hello,

This question is probably not specific to Tomcat, but a Tomcat-specific
answer could well suit my needs.

I have an application which I have split in several different contexts.
I have done so, to allow different kinds of access to the app,


depending


on the web server the requests are coming from.

However, I need a common unique component that "ties" all the contexts
together.

There must be a *single* instance of this component, otherwise
inconsistencies or duplicate work might arise. OTOH, it must be
accessible from all the contexts.

Calls to this component are very simple (calls to void methods) but
moderately frequent.

I have thought of several possibilities:

- Extract the component into a separate JVM, and connect to it


via socket.


- Extract the component into another context, and connect to it


via HTTP.


--- I like none of those.

- Create the instance from the first context needing it, and making it
available to all of them.
--- I like this best, but I have no idea of how to do that.


Yours sincerely,



Antonio Fiol









---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to