Mortimore, Jamie [IT] wrote:
<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.
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.
<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?
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
