Hi! Thanks for the first response. >> My goal is to persist the whole repository in the Oracle Database (except >> the search index and the revision log ;-) ) to keep backup effors >> minimal. >> I think this is a valid approach as I expect only small text files to be >> placed in the repository (and no (large) binary files). >> >> Another question aries about the cluster failover: >> * What happens if one node goes down? >> I expect on restart the failing node will "replicate" the missed updates >> from the repoistory. But as the "repository" itself is already in the >> database tables what does really happen? Is only the search index >> refreshed? > > All the journal events that the failed node missed when it was down will > be replayed when the failed node comes back. This will > 1) Cause (re-) indexing of any items that changed while offline updating
> the local lucene index > 2) invaidate any items in the shared local items state cache so that they > are refreshed from the DB when required. Ok, this is nearly what I expected. But what is is this "shared local items state cache"? Is this the normal cache every JCR node has? I would expect this cache is only filled if a item is queried for and it does not try to synchronize the complete repository in the (in-memory?) cache. And as I'm usuing OracleFileSystem and OraclePersistenenceManager the shared folder (in fact a table) should be up-to-date as the not-failed node has done its changes to the journal and the shared folder (the shared table). >> Also what happens if the local revision log / complete workspace folder >> is >> deleted? > > The instance will rebuild from the year dot using the journal. > >> I would expect that (a) the complete repository is somewhat replicated >> (see above) and (b) the search index is rebuild. According to the >> repository size that might take some time but should work without user >> interaction. Is that right? > > Correct > >> Though what is a recommended place for the local JCR "workspace folder" >> as >> it only contains the search index and the revision log? > > and iirc some other things like config. > >> Is >> <JBOSS>/server/default/tmp a good approach? > > I would not call it tmp, its permanent local state. What is permanent on of local repository home? * The cache is in-memory (I guess), * the workspace configuration can be recreated from the repository.xml (as on the very first start), * the search index ca be rebuild and * the repository content is always up-to-date in the table. My overall goal is to minimize backup efforts and doing no backup of the nodes' local repository folder would be very nice (as I hope it can be rebuild in case of a failure). Kind regards, Sebastian
