regarding the singleton stuff, this is essentially what is happening
on javashop.sun.com which is run on top of jws. there are a couple
other "manager" type objects that come in to play as well but the
primary patterns of interest are:
singletons
proxy (eg things made calls out over http/url to pull in content)
cache/cache-manager
obj to/from db (i think this was a delegate or facade or something)
by writing a thin serlvet which was registered with the servlet engine
to load on startup which in turn obtained a singleton reference we
moved the time penalty from the first customer to the server startup
... all with no core code change.
hope this helps,
- james
Augusto Sellhorn wrote:
> > Mark de Lange wrote:
> >
> > The problem is that I don't know where to run the customer, basket and
> > product objects. One possibility is to run them in de Java Virtual
> > Machine of the HTTP-server. But how can I create and manage these
> > objects without using a servlet? For example, when the HTTP-server
> > starts, I want to create the product-instances to build the initial
> > product-catalog.
>
> You could try this (I'm doing it). Let's see you have a "server" object
> that handles customer, basket and product objects let's call it
> "ShoppingManager".
>
> Every servlet that uses "ShoppingManager" then gets a handle to that
> singleton by using
>
> ShoppingManager.getInstance()
>
> getInstance() will start the shopping manager the first time
> it is accessed. Later calls will just pass the reference to the already
> running ShoppingManager.
>
> The problem here is. Geez, I have a long init time, the first customer
> will stay there waiting for a while for ShoppingManager to start.
> One way to get around this is to write a little script that calls
> a bogus servlet that just calls getInstance() when you want to
> start your application.
>
> There might be better ways to do this, but this is a really esy way
> to do this :)
>
> > Another way is to run these objects in a Java application and let the
> > servlets communicate with this application using RMI, but I expect
> > performance problems using this method.
>
> I wouldn't do this.
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
