tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Filip Hanik" <m...@filip.net>
Subject RE: Singleton across multiple contexts
Date Sun, 15 Jun 2003 17:59:19 GMT
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:fiol.bonnin@terra.es]
> 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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message