[
https://issues.apache.org/jira/browse/DERBY-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Myrna van Lunteren updated DERBY-1040:
--------------------------------------
Description:
The store locking tests should be run with network server, locking behaviour
investigated, and a perhaps a proposal made for testing locking with network
server. For network server, the pre-fetching of data causes diffs in the
tests and I am not sure if this is expected or not. I noticed for example
such diffs in updatelocks.sql and readlocks.sql.
Below is the list of locking tests I see in store. Feel free to take one or
two and file a subtask.
EscalateLock.sql
RowLockBasic.sql
RowLockIso.sql
TableLockBasic.sql
TableLockBasic.subsql
lockTableVti.sql
readBtreeCursorLocks.subsql
readBtreeSetLocks.subsql
readCursorLocks.subsql
readSetLocks.subsql
readlocks.sql
updateBtreeCursorLocks.subsql
updateBtreeHoldCursorLocksJDBC30.subsql
updateBtreeSetLocks.subsql
updatecursorlocks.subsql
updateholdcursorlocksJDBC30.subsql
updatelocks.sql
updatelocksJDBC30.sql
updatesetlocks.subsql
RowLockIso.sql
rlliso1multi.sql
rlliso1multi.subsql
rlliso2multi.sql
rlliso3multi.sql
was:
The store locking tests should be run with network server, locking behaviour
investigated, and a perhaps a proposal made for testing locking with network
server. For network server, the prefecting of data causes diffs in the
tests and I am not sure if this is expected or not. I noticed for example
such diffs in updatelocks.sql and readlocks.sql.
Below is the list of locking tests I see in store. Feel free to take one or
two and file a subtask.
EscalateLock.sql
RowLockBasic.sql
RowLockIso.sql
TableLockBasic.sql
TableLockBasic.subsql
lockTableVti.sql
readBtreeCursorLocks.subsql
readBtreeSetLocks.subsql
readCursorLocks.subsql
readSetLocks.subsql
readlocks.sql
updateBtreeCursorLocks.subsql
updateBtreeHoldCursorLocksJDBC30.subsql
updateBtreeSetLocks.subsql
updatecursorlocks.subsql
updateholdcursorlocksJDBC30.subsql
updatelocks.sql
updatelocksJDBC30.sql
updatesetlocks.subsql
RowLockIso.sql
rlliso1multi.sql
rlliso1multi.subsql
rlliso2multi.sql
rlliso3multi.sql
> Run store locking tests with network server and investigate locking behaviour
> ------------------------------------------------------------------------------
>
> Key: DERBY-1040
> URL: https://issues.apache.org/jira/browse/DERBY-1040
> Project: Derby
> Issue Type: Improvement
> Components: Network Client, Network Server
> Affects Versions: 10.2.1.6
> Reporter: Kathey Marsden
> Labels: derby_triage10_8
>
> The store locking tests should be run with network server, locking behaviour
> investigated, and a perhaps a proposal made for testing locking with network
> server. For network server, the pre-fetching of data causes diffs in the
> tests and I am not sure if this is expected or not. I noticed for example
> such diffs in updatelocks.sql and readlocks.sql.
> Below is the list of locking tests I see in store. Feel free to take one or
> two and file a subtask.
> EscalateLock.sql
> RowLockBasic.sql
> RowLockIso.sql
> TableLockBasic.sql
> TableLockBasic.subsql
> lockTableVti.sql
> readBtreeCursorLocks.subsql
> readBtreeSetLocks.subsql
> readCursorLocks.subsql
> readSetLocks.subsql
> readlocks.sql
> updateBtreeCursorLocks.subsql
> updateBtreeHoldCursorLocksJDBC30.subsql
> updateBtreeSetLocks.subsql
> updatecursorlocks.subsql
> updateholdcursorlocksJDBC30.subsql
> updatelocks.sql
> updatelocksJDBC30.sql
> updatesetlocks.subsql
> RowLockIso.sql
> rlliso1multi.sql
> rlliso1multi.subsql
> rlliso2multi.sql
> rlliso3multi.sql
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
