Re: [FAQ] Re: OJB conf with N servlets engines, and 1 DB
hi thomas, 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? 1. Use optimistic locking (OL) to let OJB handle write conflicts between servlet engines. To use OL define a TIMESTAMP or INTEGER column and the respective Java attribute for it. In the field-descriptor of this attribute set the attribute locking=true i'm using PB to update the database. since it doesn't keep the state, i tried that PB only increments the INTEGER without generating the exception. should we manually i) start a new transaction ii) find the current object by the object to be modified's indentity iii) compare the 2 integers (in the current and new objects), and throw the exception, and rollback if they r not match iv) mark some children objects to be deleted recusively (fix the fact that PB doesn't delete children records) prior to calling store, and commit? does this approach safe within a transaction? thanks for your suggestions. i'll have a look at the JCS later :) 2. Think about caching. As you are using OL using a local cache will tend to hold more and more invalid data over time. This will decrease performance as more and more OL-Exceptions must be handled. you can either a) turn off caching complety by using the EmptyCacheImpl b) use the ObjectCachePerBrokerImpl and clear the local caches frequently. c) Use the JCS cache implementation (see OJB.properties). JCS provides synchronisation mechanisms for distributed caches. Please have a look at the JCS site for configuration details. 3. Use a SequenceManager that is safe across multiple JVMs. The NextVal based SequenceManagers or any other SequenceManager based on database mechanisms will be fine. I am not sure if the HighLowSeqMan is guaranteed to be safe across several JVMs 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?) The OJB c/s mode was meant to separate the persistence broker layer from the Application layer (in your case the servlet container). But as servlet and EJB based apps are quite scalable by virtue of the respective containers, it just does not make much sense to introduce another layer. That's why we dropped the c/s mode. It won't be there in the 1.0 release. In fact it's already ereased from CVS! cheers, Thomas 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: OJB conf with N servlets engines, and 1 DB
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]
Re: OJB conf with N servlets engines, and 1 DB
hi lance, cool, it's exciting to see ur idea :) i'm not sure if i get this correctly. in the servlet environment, a new thread is created and died per request. for a simple servlet code, such as a simple query, if the cache will get refreshed quickly, should we consider not to use a cache at all (since the cache gets invalidated so quick, and always get data directly from the database to fill the new cahce)?. OR there's a main cache for the process' address space, and each thread will get its own copy, then uses its copy to update against the main cache? if such main cache exists, that cache should be shared among VMs on different machines. will there be a OJB internal protocol that synchronize different VMs' cache? i.e. for all update, and delete queries, refresh other VM's caches. of course, there maybe a simply centralized register to coordinate the VMs. i get ur point about the optimistic lock, i agree with ur suggestion. as long as the cache will be synchronized, some of my tables has a field to lock it for a single user to write, like a check in/out. and i allow last win in some other cases nice to know that the SequenceManagerHighLowImpl algorithm gives unique keys in a distributed environment :) thanks - Original Message - From: Lance Eason [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Sent: Tuesday, March 18, 2003 2:21 AM Subject: RE: OJB conf with N servlets engines, and 1 DB 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] - To unsubscribe, e-mail: [EMAIL
