> -----Original Message----- > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Sent: 12 July 2004 13:05 > To: Slide Developers Mailing List > Subject: Re: StandardStore, AbstractStore, caching > > > <snip> > > However, I thought having only notifications that stuff has > changed and > > should be reloaded from persistent storage into the cache > should not do > > any harm, right? > > </snip> > > > > Correct - assuming both stores use the same underlying data > source (e.g. the same database). If both servers use > different databases (to avoid a single point of failure) or > file stores then this wouldn't work. > > This is likely to be a lack of knowledge on my side: Are there any > exisiting clustering J2EE servers that work with *more than one* data > source? I thought what gets clustered is the J2EE server, not the > database. I know Oracle has a clustering solution where it > takes care of > clustering itself, but to the outside the Oracle cluster looks like a > single server.
It is the J2EE servers that are replicated and they tend to rely on a single (or clustered) database for persistence. However it's all just data whether it's backed by an in-memory hashmap or a database. There's no reason data can't be replicated using the same method. JBoss, Tomcat and C-JDBC are amongst the projects that use JGroups for clustering. Of course you can go for clustering at the database level but this is expensive and can be difficult to administer (particularly if you don't have SA's with the knowledge). This is why I'm looking for a more light-weight solution (e.g. C-JDBC). > > Also if you only use notifications and not group messaging > then there is a lag in the update reaching the server being > notified. This could mean clients get inconsistent results. > > I understand the lag problem, but how could inconsistent results be > possible? Consider a notification of *all changed data* is send upon > commit by one cluster node. Upon receiving it another cluster node > starts a transaction in which it updates its cache and > finally commits > the cache. I do not see a single spot in time where clients > could read > inconsistent data. Consider a scenario with one client is using a slide cluster with two servers, A and B: Client writes to Server A Server A commits Server A sends notification to Server B Client reads from Server A - gets new value. Client reads from Server B - gets old (cached) value. Server B recieves notification and invalidates cache. Client reads from Server B - gets new value. OR even worse: Client writes to Server A Server A commits Server A goes down Client reads from Server A - gets new value. Client reads from Server B - gets old (cached) value. Admittedly these are *unlikely scenarios*. In the time it's taken the client to read from Server A, Server B will probably have recieved the notification and the probability of a server going down between a commit a notification send is small. However it can happen and I've seen similar scenarios. > > <snip> > > So, what I do not understand is why a transaction log would > be necessary. > > </snip> > > > > Assuming that both servers use different underlying data > sources then a transaction log would be useful under the > following circumstance: > > > > Consider a situation with two servers (server A and server > B) where store replication is enabled. > > > > 1. Client updates server A > > 2. Server B is updated successfully using replication > > 3. Server B goes down > > 4. Client updates server A > > 5. Server B can't be updated > > ... > > 6. Server B is bought back into the cluster. > > 7. Client updates server A > > 8. Server B update via replication fails because the store > used by server B is not in synch with the store used by server A. > > > > If each store maintains a transaction log then when a node > is brought back into the cluster after a failure it can > retrieve any missed updates from another node in the cluster > by comparing their transaction logs. > > > > If this functionality is not provided then recovery must be > performed manually. This means taking all servers in the > cluster off-line temporarily in order to take a snapshot of > an up-to-date data source and restoring the failed server's > data source from that. > > > > Providing automatic recovery is potentially alot of work so > I would just get replication working and think about recovery > after that. > > Hmmm, I seriously think this sort of solution is far beyond the scope > what we can reliably implement in Slide. Why not keep things simple > whithout different data sources? It's a fair point.. Unfortunately this is the kind of solution I'm looking for :( Jamie. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
