Hi Jamie!

This caching mode is already part of 2.1M1. I currently do not remeber how how the modes were called, but have a look at ExtendedStore where parameters set in Domain.xml are read and applied. I will be able to tell you more when I am back in the office on Monday.

Oliver

Mortimore, Jamie [IT] wrote:

Hi Oliver,

I would prefer to use clustering at the slide level if possible as well as some of the 
other features in 2.1. Is there anything I can look at in CVS regarding 
intra-transaction caching and is this going to be in the 2.1M2 release scheduled for 
July 31st?

Thanks,

Jamie.

-----Original Message-----
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
Sent: 08 July 2004 14:25
To: Slide Developers Mailing List
Subject: Re: StandardStore, AbstractStore, caching


Hi Jamie!

In the upcoming 2.1 release it will be possible to switch off caching by
configuration. It will also be possible to use a mode that allows for
intra-transaction caching which is much faster, but enables clustering.

Oliver

Mortimore, Jamie [IT] wrote:

Slightly off topic but... I'm going to try using cjdbc 
(http://forge.objectweb.org/projects/c-jdbc) to connect a JDBCStore to two databases 
in order to create a fault tolerant webdav service. There will also be two slide 
servers:

--------      --------
| slide  |    | slide  |
| server |    | server |
| 1      |    | 2      |
--------      --------
   |             |
--------      --------
| CJDBC  |----| CJDBC  |
--------\    /--------
   |     \  /    |
   |      \/     |
--------  /\  --------
| DB1    |/  \| DB2    |
--------      --------

If one slide server or one database becomes unavailable the system will still be 
operational. In order for this to work neither slide server should cache (if 1 updates 
the db and 2 has a cached version, 2 will not see the update).

I had a quick look at the src for slide 2.0 and it looks like caching is not 
configurable (cacheResults returns true in 
org/apache/slide/common/AbstractServiceBase.java). So, just to confirm, in order to 
switch caching off I will have to extend JDBCStore and overide cacheResults to return 
false?

In addition I would be interested if anyone has any feedback on the above architecture 
(eg will it work?). It does not have to be super responsive but must be fault tolerant 
because, if all goes well, many other business critical systems will be relying on the 
system availability.

Regards,

Jamie.

-----Original Message-----
From: Andreas Probst [mailto:[EMAIL PROTECTED]
Sent: 08 July 2004 06:35
To: Slide Developers Mailing List
Subject: Re: StandardStore, AbstractStore, caching


Hi Oliver,

thank you for the quick response. Sorry, but I copied it from cvs head. It's not fixed there. Below are the ID tags.

/home/cvspublic/jakarta-slide/src/share/org/apache/slide/store/AbstractStore.java,v 
1.42 2004/06/23 09:13:42 ozeigermann Exp $
/home/cvspublic/jakarta-slide/src/share/org/apache/slide/store/StandardStore.java,v 
1.22 2004/02/11 11:30:18 ozeigermann Exp $

Regards,

Andreas

On 7 Jul 2004 at 23:54, Oliver Zeigermann wrote:



Andreas Probst wrote:


for the project I'm working in I need to change the caching behaviour of Slide. Looking at StandardStore, which does the caching, I wonder:

If caching is disabled, read calls are forwarded to super (AbstractStore), which then calls the actual Store implementation.

If caching is enabled but the object to read is not in the cache, the calls are not forwarded to super but to the actual Store implementation, e.g. DescriptorsStore.

Why is it done this way? Is it just style?
When super is called, the Stores are listed in a transaction...

I guess you are referring to 2.0, right? I have done this stuff and as far as I remember, it was just non sense and I fixed it in the current CVS head.


Oliver




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









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




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to