Why not just run in clustered configuration, i.e. multiple app-servers, on
the same or different machines? In my experience (with clustering), the
rate-limiting thing is the amount of processor available to GF, not the
number of copies of code available to the app-server. The classloader isn't
going to care which JNDI tree your particular instance of some @Stateless
interface is coming from, right? It's just going to grab the "nearest" one
out of the cache. As long as the server thread is running on one CPU core,
it doesn't matter how many copies of your jar file you have lying around,
your requests are just going to logjam on the processor.
Just my 2cents...
Jason
On 5/10/07, Shevland, Joe <joe.shevland_at_capgemini.com> wrote:
>
>
> > * If instead its clustered, because there's just one
> > deployment ear, how would I map three 'instances' to three
> > different configurations or different JNDI names for each?
> > Each module is going to open a server socket (yes its
> > probably going outside the spec) and I'd like to feed them
> > each a different port.
>
> I guess each server instance is going to have its own JNDI tree... in
> any case, what ObjectFactory would you use for 'simple'/constant JNDI
> resources?
>
> Cheers
> Joe
>
> This message contains information that may be privileged or confidential
> and is the property of the Capgemini Group. It is intended only for the
> person to whom it is addressed. If you are not the intended recipient, you
> are not authorized to read, print, retain, copy, disseminate, distribute,
> or use this message or any part thereof. If you receive this message in
> error, please notify the sender immediately and delete all copies of this
> message.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>