I just went through this exercise myself, so what I know:

  - first off it is probably best to either pull the latest from CVS or wait for 1.0 
rc2.  Armin recently did some significant refactoring of the caching code and it is 
much improved

  - in OJB.properties set 
'ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl' - this will do 
two things it will give you a broker-specific cache so brokers working at the same 
time on different threads won't step on each other and it will also cause the cache to 
be refreshed each time a broker is retrieved from the pool

  - the way I use the brokers is to get a broker at the beginning of my web request, 
use that broker for the duration of the request and then commit/abort it at the end of 
the request and release it back to the pool.  In other words I don't hold on to 
brokers for long periods of time, this helps scalability and means that the data in my 
cache doesn't get too stale.

  - as long as you use ObjectCachePerBrokerImpl and use a dedicated broker per request 
you shouldn't have to worry about synchronizing access to your objects.  You will 
however have to worry about OptimisticLockExceptions when updating your objects.  
Unless you're comfortable with last one wins semantics (which you shouldn't be for 
most apps), you should add timestamp or integer columns to each of your tables to 
store a version number for the record.  In the field descriptor for this column add 
locking="true" to tell OJB that this column is for optimistic locking.  Your app 
should then be prepared to handle OptimisticLockExceptions.  Because I don't expect 
these to happen often I reshow the same page with the updated data from the database 
and an error message asking the user to resubmit their changes.

  - any data I want to cache for extended periods of time, e.g. rarely changed lookup 
tables, etc., I implement as a cache above OJB holding on to the objects returned from 
OJB queries.

  - finally for unique sequences just specify the High Low Sequence Manager inside 
your jdbc-connection-descriptor and mark you're primary key field-descriptors with 
primarykey="true" and autoincrement="true", OJB will take care of the rest.
     <jdbc-connection-descriptor ...lots of attributes...>
        <sequence-manager 
className="org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl">
            <attribute attribute-name="grabSize" attribute-value="20"/>
        </sequence-manager>
     </jdbc-connection-descriptor>

-----Original Message-----
From: Thomas Phan [mailto:[EMAIL PROTECTED]
Sent: Monday, March 17, 2003 11:52 AM
To: OJB Users List
Subject: OJB conf with N servlets engines, and 1 DB


Hi,

In a single web site + load-balanced/cluster environment, if I have more
than 1 servlet engines (different VMs/HTTP sessions), each runs an OJB
instance, and 1 shared database, what OJB mode should I configure to get the
data cached (clear for all dirty cache automatically), synchronized, and
obtain unique sequence?

Is that something like the C/S mode? but all HTTP requests go to the cluster
of PB servers (no PB clients will exist in this case?)

Thanks

Thomas


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to