On Jul 15, 2006, at 9:44 PM, Bill Dudney wrote:
Here are the original 4 options that you posted (I numbered them
for reference);
Might be more options, just posted what was immediately in my head.
(1)- one session id per client vm
(2)- one session id per client connection
(3)- one session id per login (security scoped)
(4)- one session id per remote ejb proxy
I prefer 4 because it will work best with what I expect to be the
most typical use case (but I could be wrong so please point out
better info if I am). Typical being a web app connected to the ejb
tier.
Certainly 4 is the finest grain session id you could get. It would
literally mean that each session bean instance is clustered
independently with no concept of affinity or awareness of who "owns"
it be that a webapp or plain java client.
If this were a web container that'd be simple as a "client" can only
have one session. Obviously with ejb though a client can have
multiple session beans so things may get hairy.
Although 3 is probably close enough to 4 that it would not cause
conflict in the items in the cache being locked. I think both 1 and
2 would cause lots of conflict in what is being locked.
It's relative really. More on that below.
Now I'm full of questions :-)
What are the motivations/benifits/costs WRT the current openejb
code base WRT the 4 options?
How is the sessionid concept currently implemented (if at all)?
The current sessionid concept if for tracking session bean instances
and has no awareness or concept of who "owns" a session bean
instance. You could cluster around that sessionid, but without some
sort of id to track the "owner", when a fail-over occurs each
instance would be treated as one unit and the "owner" may end up with
bean references now across a few different servers.
Do you have a preference one way or the other? (as was said earlier
less code change is better, at least in the beginning :)
If you wanted to get started with simply clustering on session bean
ids individually, that'd certainly involve very little code change.
Definitely, though, for an optimal clustering scenario that still
works after a fail-over, you want to end up with all the client's
data in the same place, so you'll still need to define what a
"client" is. That's where the relativity comes in.
For an standalone java app using ejbs, the "client" id could very
well be some static it's VM. For the situation of a webapp, the
client is not the server vm but the closest thing that represents the
client connected to the vm, which is likely the servlet session.
As for how to pull that off, that's where the real work is. Your
guess is as good as mine.
-David
TTFN,
-bd-
On Jul 14, 2006, at 4:43 PM, David Blevins wrote:
The question hasn't been answered at a concrete level I was
looking for. To play along... the session id is tied to the
"client", fine. What is a client and how do we identify one? ;)
-David
On Jul 12, 2006, at 8:56 AM, Jeff Genender wrote:
Ok...then I think we are in agreement then here ;-)
Bill Dudney wrote:
Hi Jeff,
That might be the current impl. But this whold thread was to
discuss what the session id should be.
I'm trying to say that of the 4 options presented at the root of
this thread I'd prefer that the session ID be tied to the
particular client which would lead to the smallest glob of stuff
that gets locked.
if we go with the first option (again from the root of the
thread) we would have a session id per client vm, that is what I
don't want.
-bd-
On Wednesday, July 12, 2006, at 11:36AM, Jeff Genender
<[EMAIL PROTECTED]> wrote:
Bill Dudney wrote:
If the seesion id is tied to the client vm, i.e. the web vm
then there is one session id per web tier vm (which in all
likelyhood has many many users).
Hmmm...I don't think I agree here. I believe the session id is
tied to
the client...period. There is one id per session per
client...not web
tier vm. Maybe you can explain what you are thinking?
Its my understanding the session id is like a web session...that
particular client gets a unique id that represents only that
session for
that client.
Jeff
