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
Hi,

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 10.2.0.3.0, 11.2.0.2.0

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
file.

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
   http://www.java2s.com/Code/Java/Database-SQL-JDBC/UpdatingaRowinaDatabaseTableUsinganUpdatableResultSet.htm

Regards,
S. Dahlberg


Mime
View raw message