Hi Folks,
Being a fairly senior Java/Distributed System guy ... but being _very_ new
to EJB ... and being under the gun to deliver iterations ... I need to blurt
out a question that is likely obvious and documented ... and hope for an
easy answer.
Generically or specifically ...
(specifically)
TopLINK and Weblogic 5.1 (going to 6.0)
(generically || specifically)
In the case of a "cluster" of bean servers ... where all of your servers in
the cluster have a deployment of all of your beans.
As well, let's say the basic configuration is that a client (JSP), does a
JNDI lookup (get home) and create() on a Stateless Session Bean (controller)
which in turn does a JNDI lookup (get home) and create() on a Stateless
Session Bean (manager) which in turn does JNDI lookup (get home) and
create() on a specific type of Entity (the "type" that the given "manager"
... "manages").
JSP -> Controller ----> ManagerTypeA -> EntityTypeA
|
-----> ManagerTypeB -> EntityTypeB
.
.
.
(and so on ...)
What I am trying to understand is some of the semantics of this under the
covers.
Does a "home" stub _imply_ that operations on the home stub e.g. create()
are "home"'d to a given JVM in the cluster for the lifetime of that instance
of that home interface ... or will create()s always be "round robin" to
instances of JVM's in the cluster that have that bean deployed.
Said a different way, in the case of a cluster where it is implied that the
cluster is there to support load through replication ... where does the
round-robin occur ... at "lookup" time of a given type of "home" ... or
"create" time through the specific "home" stub instance.
Are there any generic/specifc assumptions that can be made about
optimizations with regard to create()s ... i.e. ... if a "controller" does a
lookup/create() on a "manager" ... then it would _seem_ that it would be
optimal to have the "controller" instance and the "manager" instance in the
same JVM/process where possible ?
These questions are born from some discussion around any efficiences that we
might gain by having our "controller" and "manager" beans "cache" as
attributes "home" stubs ... and potentially "remote" stubs.
Some have even suggested that we encapsulate "caching" of stubs in the
"generic" service in our infrastructure ... which personally makes me _very_
uncomfortable ... but I don't yet know why.
Thanks for _any_ help based on your own real experiences ... or any pointers
to information on actual implementation experience ... as oppossed ot stuff
steeped in acadamiea.
TIA,
Tony
---
Tony Pelton
Developer
tpelton at imany dot com
http://www.i-many.com
"Hail to the King, Baby"
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
