Lemme try with a 'from' address that will be accepted.

-- 
Dan Christopherson (danch) 
nVisia Technical Architect (www.nvisia.com)

Opinions expressed are mine and do not neccessarily reflect any 
position or opinion of nVISIA.

---------------------------------------------------------------------------
If you're a capitalist and you have the best goods and they're 
free, you don't have to proselytize, you just have to wait.
-Eben Moglen

---------- Forwarded message ----------
Date: Thu, 22 Feb 2001 16:56:28 -0600 (CST)
From: Dan Christopherson <[EMAIL PROTECTED]>
To: JBoss-Dev <[EMAIL PROTECTED]>
Subject: Re: [jBoss-Dev] Article on clustering

On Thu, 22 Feb 2001, Dan OConnor wrote:

> 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. 
The entity would be constrained to existing on one and only one server in
the cluster.

> 
> A clustered entity would use commit option "C", right? 
Not if they're pinned.

> So the 
> claim that it would be too expensive to have multiple copies of the 
> same entity seemed obviously false. 
It depends on how the vendor you work for implemented clustering
8^}). It also depends on which 'expense' you're optimising for - network
traffic for cache coherency (if you allow commit option <> C, but no
pinning), database accesses (if you force commit option C), memory use,
container developer time...

> However, I can envision many 
> scenarios where a stateful session bean might get pinned to a 
> server. 
That makes good sense, although then you wouldn't be able to fail-over.


> 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?
I think 'Strange commit option A scenario' is what he was thinking. I
think allowing commit option A for entities leads to complexity no matter
how you implement it - cache coherency or pinning.

That (and stateful sessions) is where clustering gets fun - I was kind of
dissappointed that the guy spent his time doing the hand-wave thing about
how you do the location bit and never got to this meaty bit.

> 
> -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]
> > 
> 
> 
> 

-- 
Dan Christopherson (danch) 
nVisia Technical Architect (www.nvisia.com)

Opinions expressed are mine and do not neccessarily reflect any 
position or opinion of nVISIA.

---------------------------------------------------------------------------
If you're a capitalist and you have the best goods and they're 
free, you don't have to proselytize, you just have to wait.
-Eben Moglen



Reply via email to