AW: OJB caching and concurrent access

Hi Alessandro,

thanks for your response. However, as the long transactions involve externa=
l devices and systems and a strictly sequential order must be assured, I th=
ink optimistic locking is not helpful at all. Besides that, OpenSymphony se=
ems to be interesting anyway.

Best regards

Bernd

-----Urspr=FCngliche Nachricht-----
Von: Alessandro Colantoni [mailto:[email protected]]=20
Gesendet: Mittwoch, 18. M=E4rz 2009 16:51
An: OJB Users List
Betreff: Re: OJB caching and concurrent access

Hi Bernd,

did you consider to use the OSCasche implementation with optimistic locking=
?

http://db.apache.org/ojb/docu/guides/objectcache.html#ObjectCacheOSCacheImp=
l
http://db.apache.org/ojb/docu/howtos/howto-work-with-clustering.html

I used that sometimes and it is very quick as the entries are not locked,
but you got an exception where you try to store a "dirty read", so catching
it you can decide what to do.

Hope this helps

Alessandro Colantoni




On Wed, Mar 18, 2009 at 4:25 PM, Bernd L=E4ngerich
<[email protected]>wrote:

> Hello,
>
> I use the PB-API. Is there any support for concurrent access to the same
> data base entries from multiple servers/applications in OJB? In order to
> provide a scalable system and high availability, I am faced with the dema=
nds
> of load balancing and multiple servers running the same application and
> service. At the moment, multiple servers could obtain the same object
> instance from the database, caching them, perform changes and possibly
> updating the data base without notification of their neighbors. Completel=
y
> turning off caching is no real option at the moment.
>
> At the moment, my approach would be to lock the rows in the database duri=
ng
> transaction processing, thus disabling concurrent access to these entries=
.
> After transaction is done, the instance would be held in cache. If
> subsequent transactions are scheduled to the same server, everything is
> fine, but there is a possibility that another server is scheduled one
> transaction, making the cached instance obsolete. The best solution would
> be, that the object instance remains in cache, but are updated from the
> database when requested.
>
> Best regards
>
> Bernd
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>