[jira] [Comment Edited] (DERBY-7042) Multiple triggers with rowLocking = false causes deadlock

2019-04-03 Thread Michael Schuetze (JIRA)


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

Michael Schuetze edited comment on DERBY-7042 at 4/3/19 1:57 PM:
-

The bug is that the Insert and Update times are hitting the full waitTimeout 
period. If you change it to 60 seconds, those times will be 60 seconds, if you 
set them to -1, the program will sit there forever without timing out. The 
operations themselves should take less than a second.

In versions of derby prior to 10.8.2.2, this operation would perform at the 
same speed as rowLocking set to true.

Edit: This is a question of whether rowLocking has to be set to true when using 
multiple triggers on the same database table in order to prevent deadlock 
scenarios from occurring. The operations above should take milliseconds to run 
at worst, so the fact that they take 15 seconds is concerning and reason to 
suspect deadlock. If rowLocking is required to be set to true, it should be 
documented somewhere


was (Author: mjschuetze102):
The bug is that the Insert and Update times are hitting the full waitTimeout 
period. If you change it to 60 seconds, those times will be 60 seconds, if you 
set them to -1, the program will sit there forever without timing out. The 
operations themselves should take less than a second.

In versions of derby prior to 10.8.2.2, this operation would perform at the 
same speed as rowLocking set to true.

Edit: This is a question of whether rowLocking has to be set when using 
multiple triggers on the same database table in order to prevent deadlock 
scenarios from occurring. The operations above should take milliseconds to run 
at worst, so the fact that they take 15 seconds is concerning and reason to 
suspect deadlock. If rowLocking is required to be set to true, it should be 
documented somewhere

> Multiple triggers with rowLocking = false causes deadlock
> -
>
> Key: DERBY-7042
> URL: https://issues.apache.org/jira/browse/DERBY-7042
> Project: Derby
>  Issue Type: Bug
>  Components: Documentation, JDBC
>Affects Versions: 10.8.2.2, 10.8.3.0, 10.9.1.0, 10.10.1.1, 10.10.2.0, 
> 10.11.1.1, 10.12.1.1, 10.13.1.1, 10.14.1.0, 10.14.2.0, 10.15.1.3
> Environment: -- Java Information --
> Java Version:1.8.0_201
> Java Vendor: Oracle Corporation
> OS name: Linux
> OS architecture: i386
> OS version:  4.15.0-46-generic
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.8
> java.runtime.version: 1.8.0_201-b09
> - Derby Information 
> [.../TriggerRepro/derby/derby-10.14.1.0.jar] 10.14.1.0 - (1808820)
>Reporter: Michael Schuetze
>Priority: Minor
>  Labels: documentation, performance
> Attachments: Derby7042.java
>
>
> Repro for the bug can be found here: 
> [https://github.com/mjschuetze102/TriggerRepro]
> Includes a detailed README of steps that show effect of bug as well as two 
> versions of the Derby database. 10.8.1.2, the last version where the bug was 
> not present and version 10.14.1.0, for easy access.
> This may just be an issue of not having enough documentation on database 
> Triggers (see Conclusions Based on Results)
> h2. Summary of Issue
> *Having multiple triggers with {{'derby.storage.rowLocking', 'false'}} causes 
> issues with deadlocking*
>  # Executing Update trigger causes deadlock when there is an Insert or Delete 
> trigger
>  # Executing Insert trigger causes deadlock when there is a Delete trigger
>  # Executing Delete trigger does not cause deadlock
> *{{'derby.locks.deadlockTimeout'}} does not seem to work in above case*
>  # While executing issue above, none of the triggers were terminated and 
> waitTimeout time was hit
> h2. Conclusions Based on Results
> *Having multiple triggers with {{'derby.storage.rowLocking', 'false'}} causes 
> issues with deadlocking*
> Triggers seem to get into deadlock scenarios with any trigger defined after 
> itself. If this is the case, it should be documented somewhere that 
> rowLocking needs to be enabled to use the trigger feature if multiple 
> triggers would be used on the same database table.
> *{{'derby.locks.deadlockTimeout'}} does not seem to work in above case*
> Based on documentation, I could not find any concrete evidence of whether 
> this is intended functionality.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (DERBY-7042) Multiple triggers with rowLocking = false causes deadlock

2019-04-03 Thread Michael Schuetze (JIRA)


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

Michael Schuetze edited comment on DERBY-7042 at 4/3/19 1:56 PM:
-

The bug is that the Insert and Update times are hitting the full waitTimeout 
period. If you change it to 60 seconds, those times will be 60 seconds, if you 
set them to -1, the program will sit there forever without timing out. The 
operations themselves should take less than a second.

In versions of derby prior to 10.8.2.2, this operation would perform at the 
same speed as rowLocking set to true.

Edit: This is a question of whether rowLocking has to be set when using 
multiple triggers on the same database table in order to prevent deadlock 
scenarios from occurring. The operations above should take milliseconds to run 
at worst, so the fact that they take 15 seconds is concerning and reason to 
suspect deadlock. If rowLocking is required to be set to true, it should be 
documented somewhere


was (Author: mjschuetze102):
The bug is that the Insert and Update times are hitting the full waitTimeout 
period. If you change it to 60 seconds, those times will be 60 seconds, if you 
set them to -1, the program will sit there forever without timing out. The 
operations themselves should take less than a second.

In versions of derby prior to 10.8.2.2, this operation would perform at the 
same speed as rowLocking set to true

> Multiple triggers with rowLocking = false causes deadlock
> -
>
> Key: DERBY-7042
> URL: https://issues.apache.org/jira/browse/DERBY-7042
> Project: Derby
>  Issue Type: Bug
>  Components: Documentation, JDBC
>Affects Versions: 10.8.2.2, 10.8.3.0, 10.9.1.0, 10.10.1.1, 10.10.2.0, 
> 10.11.1.1, 10.12.1.1, 10.13.1.1, 10.14.1.0, 10.14.2.0, 10.15.1.3
> Environment: -- Java Information --
> Java Version:1.8.0_201
> Java Vendor: Oracle Corporation
> OS name: Linux
> OS architecture: i386
> OS version:  4.15.0-46-generic
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.8
> java.runtime.version: 1.8.0_201-b09
> - Derby Information 
> [.../TriggerRepro/derby/derby-10.14.1.0.jar] 10.14.1.0 - (1808820)
>Reporter: Michael Schuetze
>Priority: Minor
>  Labels: documentation, performance
> Attachments: Derby7042.java
>
>
> Repro for the bug can be found here: 
> [https://github.com/mjschuetze102/TriggerRepro]
> Includes a detailed README of steps that show effect of bug as well as two 
> versions of the Derby database. 10.8.1.2, the last version where the bug was 
> not present and version 10.14.1.0, for easy access.
> This may just be an issue of not having enough documentation on database 
> Triggers (see Conclusions Based on Results)
> h2. Summary of Issue
> *Having multiple triggers with {{'derby.storage.rowLocking', 'false'}} causes 
> issues with deadlocking*
>  # Executing Update trigger causes deadlock when there is an Insert or Delete 
> trigger
>  # Executing Insert trigger causes deadlock when there is a Delete trigger
>  # Executing Delete trigger does not cause deadlock
> *{{'derby.locks.deadlockTimeout'}} does not seem to work in above case*
>  # While executing issue above, none of the triggers were terminated and 
> waitTimeout time was hit
> h2. Conclusions Based on Results
> *Having multiple triggers with {{'derby.storage.rowLocking', 'false'}} causes 
> issues with deadlocking*
> Triggers seem to get into deadlock scenarios with any trigger defined after 
> itself. If this is the case, it should be documented somewhere that 
> rowLocking needs to be enabled to use the trigger feature if multiple 
> triggers would be used on the same database table.
> *{{'derby.locks.deadlockTimeout'}} does not seem to work in above case*
> Based on documentation, I could not find any concrete evidence of whether 
> this is intended functionality.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DERBY-7042) Multiple triggers with rowLocking = false causes deadlock

2019-04-03 Thread Michael Schuetze (JIRA)


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

Michael Schuetze commented on DERBY-7042:
-

The bug is that the Insert and Update times are hitting the full waitTimeout 
period. If you change it to 60 seconds, those times will be 60 seconds, if you 
set them to -1, the program will sit there forever without timing out. The 
operations themselves should take less than a second.

In versions of derby prior to 10.8.2.2, this operation would perform at the 
same speed as rowLocking set to true

> Multiple triggers with rowLocking = false causes deadlock
> -
>
> Key: DERBY-7042
> URL: https://issues.apache.org/jira/browse/DERBY-7042
> Project: Derby
>  Issue Type: Bug
>  Components: Documentation, JDBC
>Affects Versions: 10.8.2.2, 10.8.3.0, 10.9.1.0, 10.10.1.1, 10.10.2.0, 
> 10.11.1.1, 10.12.1.1, 10.13.1.1, 10.14.1.0, 10.14.2.0, 10.15.1.3
> Environment: -- Java Information --
> Java Version:1.8.0_201
> Java Vendor: Oracle Corporation
> OS name: Linux
> OS architecture: i386
> OS version:  4.15.0-46-generic
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.8
> java.runtime.version: 1.8.0_201-b09
> - Derby Information 
> [.../TriggerRepro/derby/derby-10.14.1.0.jar] 10.14.1.0 - (1808820)
>Reporter: Michael Schuetze
>Priority: Minor
>  Labels: documentation, performance
> Attachments: Derby7042.java
>
>
> Repro for the bug can be found here: 
> [https://github.com/mjschuetze102/TriggerRepro]
> Includes a detailed README of steps that show effect of bug as well as two 
> versions of the Derby database. 10.8.1.2, the last version where the bug was 
> not present and version 10.14.1.0, for easy access.
> This may just be an issue of not having enough documentation on database 
> Triggers (see Conclusions Based on Results)
> h2. Summary of Issue
> *Having multiple triggers with {{'derby.storage.rowLocking', 'false'}} causes 
> issues with deadlocking*
>  # Executing Update trigger causes deadlock when there is an Insert or Delete 
> trigger
>  # Executing Insert trigger causes deadlock when there is a Delete trigger
>  # Executing Delete trigger does not cause deadlock
> *{{'derby.locks.deadlockTimeout'}} does not seem to work in above case*
>  # While executing issue above, none of the triggers were terminated and 
> waitTimeout time was hit
> h2. Conclusions Based on Results
> *Having multiple triggers with {{'derby.storage.rowLocking', 'false'}} causes 
> issues with deadlocking*
> Triggers seem to get into deadlock scenarios with any trigger defined after 
> itself. If this is the case, it should be documented somewhere that 
> rowLocking needs to be enabled to use the trigger feature if multiple 
> triggers would be used on the same database table.
> *{{'derby.locks.deadlockTimeout'}} does not seem to work in above case*
> Based on documentation, I could not find any concrete evidence of whether 
> this is intended functionality.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)