OJB caching and concurrent access

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OJB caching and concurrent access

Bernd Längerich
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 demands 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. Completely turning off caching 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 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OJB caching and concurrent access

Alessandro Colantoni
Hi Bernd,

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

http://db.apache.org/ojb/docu/guides/objectcache.html#ObjectCacheOSCacheImpl
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ängerich
<[hidden email]>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 demands
> 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. Completely
> turning off caching 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
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: OJB caching and concurrent access

Ron Bagdanoff
In reply to this post by Bernd Längerich
Don't know if anyone has responded to you on this, but what you need is a distributed cache implementation.  Unfortunately OJB does not have a distributed cache.  We are using OJB for our product and we had to build our own distributed 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 and 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.  

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 distributed cache feature, but you will have to write you own implementation to 'hook it up' to the OJB PB events.

Hope that helps.

Regards
Ron Bogdanoff
Serus Corp

-----Original Message-----
From: Bernd Längerich [mailto:[hidden email]]
Sent: Wednesday, March 18, 2009 8:25 AM
To: [hidden email]
Subject: OJB caching and concurrent access

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 demands 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. Completely turning off caching 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 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: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: OJB caching and concurrent access

Bernd Längerich
In reply to this post by Alessandro Colantoni
Hi Alessandro,

thanks for your response. However, as the long transactions involve external devices and systems and a strictly sequential order must be assured, I think optimistic locking is not helpful at all. Besides that, OpenSymphony seems to be interesting anyway.

Best regards

Bernd

-----Ursprüngliche Nachricht-----
Von: Alessandro Colantoni [mailto:[hidden email]]
Gesendet: Mittwoch, 18. März 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#ObjectCacheOSCacheImpl
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ängerich
<[hidden email]>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 demands
> 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. Completely
> turning off caching 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
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: OJB caching and concurrent access

Bernd Längerich
In reply to this post by Ron Bagdanoff
Ron,

thank you for your helpful hints.

Best regards

Bernd

-----Ursprüngliche Nachricht-----
Von: Ron Bagdanoff [mailto:[hidden email]]
Gesendet: Mittwoch, 18. März 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 distributed cache implementation.  Unfortunately OJB does not have a distributed cache.  We are using OJB for our product and we had to build our own distributed 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 and 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.  

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 distributed cache feature, but you will have to write you own implementation to 'hook it up' to the OJB PB events.

Hope that helps.

Regards
Ron Bogdanoff
Serus Corp

-----Original Message-----
From: Bernd Längerich [mailto:[hidden email]]
Sent: Wednesday, March 18, 2009 8:25 AM
To: [hidden email]
Subject: OJB caching and concurrent access

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 demands 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. Completely turning off caching 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 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: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...