[ 
https://issues.apache.org/jira/browse/DERBY-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160838#comment-14160838
 ] 

Myrna van Lunteren commented on DERBY-1040:
-------------------------------------------

the updatelocks.sql test (with subsql files updatesetlocks.subsql, 
updatelocks.sql, updatesetlocks.subsql) was converted to junit with DERBY-5305. 
I merged the updatelocksJDBC30.sql (with *JDBC30.subsql) into the converted 
UpdateLocksTest and then switched the suite to run defaultSuite rather than 
embeddedSuite for DERBY-6247.
RowLockBasic.sql was converted to RowLockBasicTest for DERBY-5147 and runs with 
defaultSuite.
TableLockBasic.sql was converted to TableLockBasicTest for  DERBY-5301 and runs 
with defaultSuite.



> 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)

Reply via email to