Dan wrote:
>Did you notice how it describes how an entity bean might get
>"pinned" against a single server in the cluster? Did you understand
>this? It didn't make a whole lot of sense to me.
we had this discussion a long time ago :)
A pinned entity handle (remote stub) points to only one server.
So if your EJB client has a remote handle to a pinned entity, that handle
points to one server only.
This means that if the server goes down, the client would have to look up
the home in the JNDI tree and request a new handle for the same entity.
If the object wasn't pinned, the remote handle would automatically connect
to a entity replica (the entire entity bean replicated into another VM or
server) on another server or process.
The problem with this is that an entity bean is stateful and usually handles
persistent data. This means that operation of replicating this object and
keeping the data integrity is very expensive.
Gemstone has a pretty neat solution to this where the have distributed
locking and can represent the same entity on multiple VMs. I haven't worked
with gemstone for a long time, so I'm not sure where they are today.
Hope this helps Dan, feel free to shoot out other questions.
Filip
~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
[EMAIL PROTECTED]
www.filip.net
----- Original Message -----
From: "Dan OConnor" <[EMAIL PROTECTED]>
To: "JBoss-Dev" <[EMAIL PROTECTED]>
Sent: Thursday, February 22, 2001 10:06 AM
Subject: Re: [jBoss-Dev] Article on clustering
Hey Rickard,
Thanks for the pointer to the article.
Did you notice how it describes how an entity bean might get
"pinned" against a single server in the cluster? Did you understand
this? It didn't make a whole lot of sense to me.
A clustered entity would use commit option "C", right? So the
claim that it would be too expensive to have multiple copies of the
same entity seemed obviously false. However, I can envision many
scenarios where a stateful session bean might get pinned to a
server. Do you think this is what he was reaching for? Or was he
referring to some strange clustered commit option "A" scenario, or
maybe a client-managed transaction?
-Dan
On 22 Feb 01, at 13:43, Rickard Öberg wrote:
> Hey
>
> You may want to read this:
> http://www.onjava.com/pub/a/onjava/2000/12/15/ejb_clustering.html
>
> regards,
> Rickard
>
> --
> Rickard Öberg
>
> Email: [EMAIL PROTECTED]
>