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]

Reply via email to