I don't know about JCS features. Does it have an invalidation mechanism?
That if an Object O1 with identity X is manipulated in VM1 all Objects 02 - On with the same identity but residing in other VMs are removed from JCS caches automatically?
Or does it contain an update mechanism that propagates object manipulations accross VMs? If so, how are write conflicts handled?
How are ACID features maintained?
If JCS can do one of these aproaches properly we can kick out all our invalidation stuff!
cheers,
Thomas
Matthew Baird wrote:
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>
------------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:ojb-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:ojb-user-help@;jakarta.apache.org>
-- To unsubscribe, e-mail: <mailto:ojb-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:ojb-user-help@;jakarta.apache.org>
