Krish, I have a CMP entity bean that associated with table in database. This table has one filed called STATUS. In this table some rows are read only (if status is marked CLOSED or CANCEL) and some rows can be modify (if status is OPEN). Also application also inserts rows with status OPEN.
I would like to cache those rows that have a status CLOSED or CANCEL. Do your AppServer support this kind of caching? Deepak -----Original Message----- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Krishnan Subramanian Sent: Thursday, November 15, 2001 9:30 AM To: [EMAIL PROTECTED] Subject: Re: Data caching in a J2EE world Kenneth, <vendor> In our AppServer product, you can use transaction commit option's A & B combined with our caching technology. In short, many AppServer vendors support a pool of entity beans (the pool contains instances _not_ associated with a primary key). Our AppServer in addition to the above pool also support a cache. If you use Option A (EJB 1.1 & 2.0 specs), then the cache contains entity bean instances. These instances know about their primary key as well as state (state as in CMP field values). If you use Option B (again transaction commit option in the EJB 1.1 & 2.0 specs), the cache contains the entity bean instance and this time around, the instance knows only about its primary key and not state (state again as in CMP field values). Hence, if your AppServer has exclusive access to the database, or you have specific tables that are read-only or insert-only (i.e. inserts can be done over time but existing rows cannot be modified by an application other than a single ejb server), then our AppServer product provides entity bean support with no database access. In other words, a pure middle tier data cache! The above works because (a) Option A suppresses reads from the database when the instance is in the cache and (b)our difference detection engine in our CMP implementation eliminates writes to the database (i.e. ejbStores) if no fields were modified. If you use Option B, then our cache contains the entity bean instance with its associated primary key. And only an ejbLoad is necessary to synchronize the state of the entity bean with the state in the database. Of course, the size of the pool and cache can be configured at deployment time according to hardware availability and your application needs. </vendor> -krish > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]]On Behalf Of Kenneth D. Litwak > Sent: Wednesday, November 14, 2001 7:49 PM > To: [EMAIL PROTECTED] > Subject: Data caching in a J2EE world > > > Apart from haivng big stateful session beans, what are some ideas on how to > cache file data or database data in an EJB/J2EE environment? Thanks. > > Ken > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
