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>
