AW: OJB caching and concurrent access

Ron,

thank you for your helpful hints.

Best regards

Bernd

-----Urspr=FCngliche Nachricht-----
Von: Ron Bagdanoff [mailto:[email protected]]=20
Gesendet: Mittwoch, 18. M=E4rz 2009 16:55
An: OJB Users List
Betreff: RE: OJB caching and concurrent access

Don't know if anyone has responded to you on this, but what you need is a d=
istributed cache implementation.  Unfortunately OJB does not have a distrib=
uted cache.  We are using OJB for our product and we had to build our own d=
istributed cache using JCS and JMS. It is a fair amount of work to do this =
plus you will need to maintain that code.

If this is not an existing system and you have not committed to using OJB I=
 would strongly suggest using Hibernate.  Hibernate has a pluggable cache a=
nd a few open source projects have distributed caches for Hibernate such as=
 EhCache and JBoss cache.  We are starting to use Hibernate and EhCache on =
a new project and it is much more robust than OJB. =20

If your project uses OJB and you must continue using it, you might what to =
investigate using EhCache as a custom level two cache and use it's distribu=
ted cache feature, but you will have to write you own implementation to 'ho=
ok it up' to the OJB PB events.

Hope that helps.

Regards
Ron Bogdanoff
Serus Corp

-----Original Message-----
From: Bernd L=E4ngerich [mailto:[email protected]]=20
Sent: Wednesday, March 18, 2009 8:25 AM
To: [email protected]
Subject: OJB caching and concurrent access

Hello,

I use the PB-API. Is there any support for concurrent access to the same da=
ta base entries from multiple servers/applications in OJB? In order to prov=
ide a scalable system and high availability, I am faced with the demands of=
 load balancing and multiple servers running the same application and servi=
ce. At the moment, multiple servers could obtain the same object instance f=
rom the database, caching them, perform changes and possibly updating the d=
ata base without notification of their neighbors. Completely turning off ca=
ching is no real option at the moment.

At the moment, my approach would be to lock the rows in the database during=
 transaction processing, thus disabling concurrent access to these entries.=
 After transaction is done, the instance would be held in cache. If subsequ=
ent transactions are scheduled to the same server, everything is fine, but =
there is a possibility that another server is scheduled one transaction, ma=
king the cached instance obsolete. The best solution would be, that the obj=
ect instance remains in cache, but are updated from the database when reque=
sted.

Best regards

Bernd


---------------------------------------------------------------------
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]