jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sander Dahlberg <Sander.Dahlb...@gxsoftware.com>
Subject Oracle file system in a cluster
Date Mon, 12 Dec 2011 10:03:39 GMT

We're currently dealing with a race condition using the OracleFileSystem class in a clustered
environment. Whenever a nodetype is (un)registered the custom nodetypes - represented in an
xml file - are stored as a blob value. This action is propagated to every node in the cluster
(whether or not readonly), resulting in concurrent updates on the same database row. 'Normally'
not a problem, but Oracle requires a row to be explicitly locked whenever a blob value is
updated (see 1 - notes section, 2).

Without row locking, the custom_nodetypes.xml file might end up corrupted. In case a restart
is performed in this state the system cannot startup anymore. The only way out is restoring
a database backup.

Possible solutions we've considered:
* Use Oracle9FileSystem instead of OracleFileSystem. It uses special blob handling by creating
a temporary blob explicitly before updating (see JCR-1525). No documentation evidence found
why oracle does lock the row in this case, though I've empirically confirmed. However, it
does not use pure JDBC. Due to JCR-1907 it will only work if connection isn't wrapped.
* Another approach that could leave autocommit on is to use an updatable resultset (3). This
solution has proven to work in combination with Tomcat, but we currently have some trouble
with Websphere as the returned result set is downgraded to a read only one.
* Refactor DatabaseFileSystem to set autocommit off and use the SELECT... FOR UPDATE mechanism,
before updating the row.

Our setup:
* jackrabbit 1.6.4 (However, I don't see this is not an issue in 2.4-SNAPSHOT)
* FileSystem class: org.apache.jackrabbit.core.fs.db.OracleFileSystem
* db: oracle 11g
* driver: Oracle JDBC driver,

Tested using:
* a custom_nodetypes.xml file of size approx. 1.1MB
* easier reproduction by lowering the syncdelay
* a recurring task that registers a node type, retrieves the custom_nodetypes.xml directly
and tries to parse the XML. In case of a parse exception, the last update has corrupted the

Do you have any additional ideas how to handle this issue?

1) http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/oralob.htm#i1058044
2) http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28393/adlob_working.htm#i1010367
3) http://stackoverflow.com/questions/862355/overcomplicated-oracle-jdbc-blob-handling?answertab=votes#tab-top

S. Dahlberg

View raw message