How about taking advantage of the app server for clustering? I'm not
familiar enough with Slide's internals yet to know if this would work,
but I know most (all?) the major app servers have built-in clustering
support for sessions.

-James

>>> [EMAIL PROTECTED] 7/9/2004 1:26:45 PM >>>
My very *personal* impression is that Slide could need improvements for

clustering. However, a redundancy solution might look like having two 
Slide instances both accessing the same RDBMS (clustering will not work

with the default file store). This RDBMS might be a clusterd one as 
well, what ever you want.

As there is (currently) no notification mechanism (this might be 
implemented with the event stuff Daniel added) between Slide instances

and global caching might return outdated values I added this caching 
mode that only caches inside of transactions.

Oliver

James Mason wrote:

> Oliver,
> Can you elaborate on this a bit? It's something I'm *very*
interested
> in. I'm slowly integrating Slide into a Portal/CMS solution that
> failover/redundancy at every level and Slide is sticking out a bit
like
> a sore thumb :).
> 
> -James
> 
> 
>>>>[EMAIL PROTECTED] 7/8/2004 6:25:08 AM >>>
> 
> 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] 


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

Reply via email to