Forum Stats

  • 3,770,449 Users
  • 2,253,116 Discussions


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

keithwall Member Posts: 29
edited Mar 19, 2017 5:59PM in Berkeley DB Java Edition

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.

Best Answer


  • Greybird-Oracle
    Greybird-Oracle Member Posts: 2,690
    edited Mar 13, 2017 8:12PM


    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.


  • Greybird-Oracle
    Greybird-Oracle Member Posts: 2,690
    edited Mar 15, 2017 1:30PM

    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.


  • Greybird-Oracle
    Greybird-Oracle Member Posts: 2,690
    edited Mar 17, 2017 12:41PM Accepted Answer

    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)


  • keithwall
    keithwall Member Posts: 29
    edited Mar 19, 2017 5:59PM

    Thanks for the confirmation and the prompt reply.

This discussion has been closed.