won't the JCS based cache I implemented offer distributed caching without running in
client-server mode?
-----Original Message-----
From: Martin J. Wells [mailto:marty@;dot.net.au]
Sent: Sun 10/27/2002 2:34 PM
To: 'OJB Users List'
Cc:
Subject: RE: Client server distributed caching
Thanks for the reply Thomas.
> Correct. Cache synchronization (by means of
> PB.invalidate(oid)) between multiple OJB caches is only implemented
for C/S mode.
> C/S mode means: The PersistenceBroker client (in your case the
> SessionBean) is running in a different JVM than the PB server.
> C/S mode is useful only if you want to scale the OJB backend. In your
> case you have already scaled the frontent (that is multiple EJB
> containers running your SessionBeans).
Actually, the app doesn't currently run EJB, just JSP/Java talking
direct SQL, the frontends/sessions are loadbalanced, but the backend/SQL
isn't. It's currently hitting the DB for everything (don't come back as
an SQL server in another life, trust me).
> > In my application's case, objects are typically bound to an
app-server
> > session, with a large number of updates occurring local to the
session.
> > However, there are exceptions where another app-server may do an
update
> > on such an object. In this case I (obviously) need to remotely
invalidate
> > the object. I'm trying to avoid having my app-servers (12 or so) all
have
> > to go across the network to get object data. We're talking
> > about a *very* high event rate (~300-500 per sec), where the vast
> > majority are on local session objects.
>
> I agree. Using C/S mode in your case is IMO not an option. C/S mode is
> much slower (factor 10 - 100) than running OJB in singlevm mode.
But faster in my case than going to the DB for everything. But the key
is local caching, with distributed synchronization.
> I recommend to implement a manual invalidation scheme. This
> is not that difficult, as OJB provides all you need.
>
> 1.You'll need a special InvaldationSessionBean providing a method
> invalidate(Identity oid). (You could also use the
> PersistenceBrokerServer SessionBean implementation for this)
>
> 2. You'll have to maintain a list of all your appservers in
> the cluster
Do you mean develop an RMI layer/protocol that communicates this between
servers? Or is there something in OJB that facilitates this already
(don't really mind).
>
> 3. Once a server updates an Object belonging to another server you
> perform a remote call on 1.) to invalidate the objects.
Regards,
Marty
--
To unsubscribe, e-mail: <mailto:ojb-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:ojb-user-help@;jakarta.apache.org>
<<winmail.dat>>
-- To unsubscribe, e-mail: <mailto:ojb-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:ojb-user-help@;jakarta.apache.org>
