Dan Christopherson (danch)
STR Technical Architect (www.str.com)
On Tue, 9 May 2000, Justin Forder wrote:
> Karl-Fredrik Blixt <[EMAIL PROTECTED]> wrote:
> >Reddy R wrote:
> >>
> >> This is a general EJB question. If there are two EJB servers (with same
> >> application logic) talking to a single database. Persistent entities will be
> >> cached from the same database. If one server changes the database with an
> >> entity how does the other one update its cache.
> >>
> >It doesn't, unless your servers are working together in a cluster (which jBoss
> >is going to do in the future :). If you have two generic EJB servers persisting
> >to the same database you can only be sure of correct entities by telling them
> >that the database is shared (and in effect forcing them to load the entity data
> >before each invocation). In doing so you, of course, have no use of the cache
> >any longer, but that's the way life goes when it comes to shared databases. :)
Actually, the container only needs to load for the first invocation within
any one transaction. This is why a lot of people (like me) will urge you
to access entities through methods on stateless sessions: the session's
method can define a transaction for you, and each entity can be fetched
once for the whole transaction.
This is one of the many many cases where we need to make trade-offs
between scalability and raw speed: the container can be faster (raw speed)
if it can assume it owns the database, but it's easier to scale if you can
have N instances of the container on M machines - it'll be slower because
it can't cache, but the performance will degrade more slowly (assuming
that your application is designed to allow for this, and your database
does row locks...)
Of course, a really _smart_ container can implement some cache coherency
type stuff across such a cluster, and a find performance curve in between
those two (right, Rickard?).
>
> ..and also, I guess, if you want to use cascaded updates or deletes,
> triggers, or stored procedures.
And if you _need_ stored procedures, not even cache coherency in the
cluster can help you (unless you can tie into a DB specific API, maybe).
>
> --
> Justin Forder
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
