HA - Effect of using a cursor without explicit transaction/non read-uncommitted.

keithwall

Our application can operate with either ReplicatedEnvironments (HA) or standard Environments (non-HA).   We have just noticed that our application, when running in HA mode, violates the rule stated in the javdoc for Cursor#getNext() and others that "In a replicated environment, an explicit transaction must have been specified when opening the cursor, unless read-uncommitted isolation is specified via the CursorConfig or LockMode parameter".   We are inadvertently calling #getNext() and #getSearchKey() on cursors from ReplicatedEnvironments without a transaction and in lock modes other than read-uncommitted.  The application has seemingly been working without error for many years despite this problem.

We intend to fix the application immediately but need to formulate a response for our existing user base. 

What harmful effects can we expect from this mistake?  The model of our application is such that it does not  actually read from an HA node until it is made master (in other words, the replica nodes are dormant, from an application perspective, until they are awoken by the election result).

We are using 5.0.104.

Thanks in advance for any advice.

Greybird-Oracle

I have confirmed this and I will remove the incorrect javadoc. Also note that Replication.CONSISTENCY_POLICY is the default consistency used when performing a read with a null Transaction parameter, see:

ReplicationConfig (Oracle - Berkeley DB Java Edition API)

--mark

Greybird-Oracle

Keith,

I believe the javadoc is incorrect and you can specify a null txn when opening a cursor and performing reads, whether you're using HA or not. I think the restriction in the javadoc was relevant in very early versions of JE HA but the restriction was quickly removed and unfortunately the javadoc was not updated.

I'll talk with others on Wednesday morning to confirm this, and I'll post back here again about it on Wednesday afternoon.

--mark

Greybird-Oracle

Keith, I'm 95% sure that it is just the javadoc that is incorrect and you don't need to change your app. But I will check on that 5% uncertainty and post back -- I'm just waiting to talk to someone who is traveling right now.

BTW, are you able to upgrade soon from JE 5.0 to a current release? I worry about being able to support you very well on such an old release.

--mark

Greybird-Oracle

I have confirmed this and I will remove the incorrect javadoc. Also note that Replication.CONSISTENCY_POLICY is the default consistency used when performing a read with a null Transaction parameter, see:

ReplicationConfig (Oracle - Berkeley DB Java Edition API)

--mark

keithwall

Thanks for the confirmation and the prompt reply.