I don't know that I'm the best tutor for this, so you bets your money, you takes your chances ;). Comments below..
>>> [EMAIL PROTECTED] 7/9/2004 2:05:08 PM >>> I do not see how this would work, but am ready to be your pupil in this matter. What I do not understand is: (1) If I add the cache to the session the application server is responsible for storing it persistent. This certainly is not what is intended with it cache, right? [James>>] Correct me if I'm wrong, but the current cache implementation isn't persistent (it's all in memory). Putting the cache in the session wouldn't be for persistence (although since Tomcat support persistent sessions that's something to watch out for), rather it would be to take advantage of an existing replication technique. (2) Additionally, I do not know how a session can be used to pass information between arbitraty cluster nodes. As you said the session will be taken over only if one node fails. [James>>] Sorry if I implied it was only good for failover. After every request Tomcat sends out any changes that happened to the session during that request. This allows the other nodes in the cluster to pick up the changes and be ready in case the first node fails. The only reason to put the cache in the session is to take advantage of this replication. Oliver [James>>] The more I look at this the less appealing using the session is, though. For one, it's tied to the current user. Since the cache kinda needs to be global this would be a problem ;). Here's info on how Tomcat replicates sessions: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/cluster-howto.html. The same technique would work for replicating changes to a cache. In fact, looking through this nice list of java caching solutions (http://www.manageability.org/blog/stuff/distributed-cache-java/view) it looks like all the ones that support distributed caching do use a similar technique. I think either taking a similar approach to replicating changes or finding a caching library that fits well with the transaction architecture are the best choices here. One thing I was thinking about with clustering, though. Are LOCKs cached at the moment? I can easily see two LOCK requests coming in to different nodes in a cluster in close proximity. If the locks are cached there's a potential for data loss. -James James Mason wrote: > Well, I'm thinking mostly about Tomcat's clustering here (so no EJBs). > Tomcat uses javagroups to persist changes in session attributes across > all the nodes in the app server. This isn't really "persistent" storage, > it just ensures that if one node drops out of the cluster users won't > notice anything. > > Since Slide already has a clusterable persistent storage mechanism > (clusterable databases, cjdbc, etc) the only issue is making sure the > local caches get refreshed when a change is made. This either means a > "hey dummy, update your cache" message, or storing the cache in a way > that changes are "shared" across the cluster. > > Just implementing the cache javagroups would work, I'm sure, but it > might (maybe) be less work to tie into preexisting clustering > technologies. I think that would mean tying the cache to a user's > session somehow, though... > > -James > > >>>>[EMAIL PROTECTED] 7/9/2004 1:33:06 PM >>> > > Yes, > > this would work for sessions, but what would be the use? AFAIK > clustering for persistent storage only works with EJBs, right? > > Oliver > > James Mason wrote: > >>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] >> >> > > > > --------------------------------------------------------------------- > 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]
