Kbase P110441: Error 210015 after 49 records are updated by Java program
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
16/10/2008 |
|
Status: Unverified
FACT(s) (Environment):
OpenEdge 10.0B
SYMPTOM(s):
Run a Java program updating records within a table
49 records are updated but then error -210015 occurs
SQLState= code=-210015
java.sql.SQLException: [JDBC OpenEdge Driver]:[]Failure getting record lock on a record from table
Two connections used, 1 to fetch the records and 1 to modify the records
Both connections are in Read Committed isolation.
CAUSE:
The program demonstrates OESQL's implementation of read stability for scrollable cursors and possible lock conflicts that can result across connections.
Read stability is sometimes referred to as cursor stability. Read stability generally refers to two things:
- if data is retrieved through a scrollable cursor, fetching the same row more than once always returns the same result.- if an application retrieves a row through a cursor, it remains unchanged, that is to say, another connection cannot update that row. This is true until the application fetches another row or the cursor is closed.
For read stability in the Read Committed isolation level, OESQL reads a record with a share lock and releases that lock when:
- the next row is fetched
- the cursor is closed
- the transaction is committed or rolled back.
The program uses two connections, 1 to fetch the records and 1 to modify the records, both in Read Committed isolation and
- uses a JDBC ResultSet object with the default attributes of sensitive to db changes and updatable.
- fetches all the rows for the result set.
The driver provides the support for these result set attribute by fetching records so that the result set reflects the most current rows in the database when the records are fetched. The driver depends on the server's cursor being maintained on the last row read so that it continues reading at the proper location within the result set. In other Words, the driver depends on the server's implementation of read stability. This ensures that inserts/updates/deletes are reflected in the result as rows are fetched. The OESQL implementation of read stability provides for the cursor being the correct location via the share lock of the record the cursor points at as the row is fetched.
The program uses two connections, the updating connection runs into a share lock on the fetching connection before the complete result set has been fetched from the server.
Since two connections are used, the application does not expect (does not need) for the result set to be:
- updatable by the fetching connection
- reflect changes to the result after fetching (scrolling)
As a result, it should use the TYPE_SCROLL_INSENSITIVE and CONCUR_READ_ONLY result set attributes so that driver can does not need to depend on read stability after it has fetched a row(s).
FIX:
Due to how the JDBC driver works (see Note), one connection needs to be modified as per example:
selectStmtSample = databaseReviewSample.createStatement(Resultset.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);