OpenJPA
  1. OpenJPA
  2. OPENJPA-379

StoreException when using a third party connection pool against Sybase

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 0.9.0, 0.9.6, 0.9.7, 1.0.0
    • Fix Version/s: 1.1.0
    • Component/s: jdbc
    • Labels:
      None
    • Environment:
      Sybase
      JConnect drivers

      Description

      org.apache.openjpa.util.DataStoreException: Cursor 'jconnect_implicit_1' was declared with a FOR UPDATE clause. This cursor was found to be read only.

      When running queries using third party connection pool and JConnect drivers

        Activity

        Hide
        Srinivasa added a comment -

        When the statement is created if the resultSetType is not specified - setFetchSize or setCursorName calls result in the ResultSet with TYPE_FORWARD_ONLY and CONCUR_UPDATABLE.

        http://manuals.sybase.com/onlinebooks/group-jc/jcg0600e/prjdbc/@Generic__BookTextView/3956

        Show
        Srinivasa added a comment - When the statement is created if the resultSetType is not specified - setFetchSize or setCursorName calls result in the ResultSet with TYPE_FORWARD_ONLY and CONCUR_UPDATABLE. http://manuals.sybase.com/onlinebooks/group-jc/jcg0600e/prjdbc/@Generic__BookTextView/3956
        Hide
        Michael Dick added a comment -

        I'm not sure this was the right fix for the problem. The change affects all databases not just Sybase.

        It seems to me that the correct fix would be to delegate the resultSet type to the DBDictionary class, rather than changing the settings for all databases.

        Show
        Michael Dick added a comment - I'm not sure this was the right fix for the problem. The change affects all databases not just Sybase. It seems to me that the correct fix would be to delegate the resultSet type to the DBDictionary class, rather than changing the settings for all databases.
        Hide
        Srinivasa added a comment -

        Yes my initial thought too was to override the prepareStatement(...) behavior in SybaseDictionary$SybaseConnection. But later noticed that our connection pool implementation is setting the ResultSetType for all DBs, so to keep it consistent I went the route of setting it at the DelegatingConnection level.

        Show
        Srinivasa added a comment - Yes my initial thought too was to override the prepareStatement(...) behavior in SybaseDictionary$SybaseConnection. But later noticed that our connection pool implementation is setting the ResultSetType for all DBs, so to keep it consistent I went the route of setting it at the DelegatingConnection level.

          People

          • Assignee:
            Unassigned
            Reporter:
            Srinivasa
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development