CMP and real data in the cache

[radl01]

Hallo all,

I have one very simple qustion. I would like to change my BMP Entity beans to CMP but don't no how to check data whether anybody changed them during some times.

In my BMP I run the folloving SQL statement

UPDATE TAB0001 SET .... WHERE ID=? AND LAST_CHANGE = ?

Are there any possibility to do in CMP.

I have to do this because an other application use the same RDBMS directly.

Thanks for any help

Jan

[juhalindfors]

This is controlled by the 'commit-option' setting of your CMP entity container. The default option B synchronizes with the DB automatically at the beginning of each transaction. Any changes done by other applications to the DB will be seen.

There are more advanced caching options available if/when you want to optimize this behavior. But in your first iteration of CMP implementation you don't have to worry about it as long as you don't change the default commit option.

[radl01]

Thank you very much,

but the problem is that I need to throw a exception when the data is not in the same state.

Is it possible to do this ? Or how can I send a message to the client that he has to reload data ?

Jan

[juhalindfors]

In JBoss 3.2 you can use optimistic locking to address this type of scenario. See the latest 3.2.x documentation on the different strategies you can use to check last update columns etc.

[radl01]

Thanks a lot. It helps me to find the right way. But can you explane me the difference between A and B or other commit options?

Jan

[juhalindfors]

Commit option A means that all data read from the database will be cached by the application server. This means that updates done by other applications will not be seen by your entity beans (unless you get creative with seppuku pattern, use cache invalidation service, etc. which is really not a bad idea when you want to scale up your application).

Commit option B/C means that the cache is valid during the lifetime of a transaction (we know we can cache the data while transaction is running as it is isolated from concurrent modifications by the database). But as soon as your transaction commits, we invalidate the entity bean state in the application server and the next transaction forces a load from the database to ensure the state of the entity is in sync with possible modifications that have been done in the database.

Commit option D says data can be cached for a period of time outside the existence of a transaction, for example for 30 seconds, a minute, half an hour, etc. This means that there is a potential risk that the data is not in sync between the application server and the database for a period of time (which is configurable by you) but for some type of applications this is perfectly acceptable.

Seppuku pattern is described in many J2EE pattern repositories. In short it allows you to programmatically invalidate an entry in cache (assuming you're using cache option that caches the state outside the scope of a transaction) using a trick in the EJB spec to dispose of the instance containing unsynchronized state.

Cache invalidation service is another way of invalidating data in the application server in case you've opted to cache over transaction boundaries. It's use is explained in the JBoss Clustering documentation.

Finally, optimistic locking does not protect data by using exclusive locks during transactions but rather caters for read-mostly scenarios where the assumption is that usually modifications succeed. Concurrent modifications are detected via different strategies (a last_updated column in the database schema for instance) and if it appears that there is a conflict, the usual rollback occurs in which case the operation can be reattempted.

HTH,

-- Juha