You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org> on 2006/08/12 01:19:14 UTC

[jira] Created: (DERBY-1683) Developer guide doc for scope of locks is incorrect for one case of repeatable read.

Developer guide doc for scope of locks is incorrect  for one case of repeatable read. 
--------------------------------------------------------------------------------------

                 Key: DERBY-1683
                 URL: http://issues.apache.org/jira/browse/DERBY-1683
             Project: Derby
          Issue Type: Bug
          Components: Documentation
    Affects Versions: 10.1.3.1, 10.1.3.0, 10.1.2.1, 10.1.1.0, 10.0.2.1, 10.0.2.0, 10.2.0.0
            Reporter: Sunitha Kambhampati
            Priority: Minor
             Fix For: 10.2.0.0


http://db.apache.org/derby/docs/dev/devguide/rdevconcepts8424.html

There is this section under single-row locks.
-------------
For TRANSACTION_READ_COMMITTED or TRANSACTION_REPEATABLE_READ isolation, Derby treats rows as cursors for SELECT statements. It locks rows only as the application steps through the rows in the result. The current row is locked.
-------------

The last statement above is not true for Repeatable read.  The last stmt needs to be changed to--

For TRANSACTION_REPEATABLE_READ isolation, the locks are released at the end of the transaction. For TRANSACTION_READ_COMMITTED,  it locks rows only as the application steps through the rows in the result. The current row is locked. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Updated: (DERBY-1683) Developer guide doc for scope of locks is incorrect for one case of repeatable read.

Posted by "Laura Stewart (JIRA)" <de...@db.apache.org>.
     [ http://issues.apache.org/jira/browse/DERBY-1683?page=all ]

Laura Stewart updated DERBY-1683:
---------------------------------

    Derby Info: [Patch Available]

> Developer guide doc for scope of locks is incorrect  for one case of repeatable read.
> -------------------------------------------------------------------------------------
>
>                 Key: DERBY-1683
>                 URL: http://issues.apache.org/jira/browse/DERBY-1683
>             Project: Derby
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.5, 10.1.2.1, 10.1.3.0, 10.1.3.1
>            Reporter: Sunitha Kambhampati
>         Assigned To: Laura Stewart
>            Priority: Minor
>             Fix For: 10.2.2.0
>
>         Attachments: derby1683.diff, derby1683_2.diff, rdevconcepts8424.html
>
>
> http://db.apache.org/derby/docs/dev/devguide/rdevconcepts8424.html
> There is this section under single-row locks.
> -------------
> For TRANSACTION_READ_COMMITTED or TRANSACTION_REPEATABLE_READ isolation, Derby treats rows as cursors for SELECT statements. It locks rows only as the application steps through the rows in the result. The current row is locked.
> -------------
> The last statement above is not true for Repeatable read.  The last stmt needs to be changed to--
> For TRANSACTION_REPEATABLE_READ isolation, the locks are released at the end of the transaction. For TRANSACTION_READ_COMMITTED,  it locks rows only as the application steps through the rows in the result. The current row is locked. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Updated: (DERBY-1683) Developer guide doc for scope of locks is incorrect for one case of repeatable read.

Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
     [ http://issues.apache.org/jira/browse/DERBY-1683?page=all ]

Rick Hillegas updated DERBY-1683:
---------------------------------

    Fix Version/s: 10.2.2.0
                       (was: 10.2.1.0)

Moving to 10.2.2.0.

> Developer guide doc for scope of locks is incorrect  for one case of repeatable read.
> -------------------------------------------------------------------------------------
>
>                 Key: DERBY-1683
>                 URL: http://issues.apache.org/jira/browse/DERBY-1683
>             Project: Derby
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.0, 10.1.2.1, 10.1.3.0, 10.1.3.1
>            Reporter: Sunitha Kambhampati
>            Priority: Minor
>             Fix For: 10.2.2.0
>
>
> http://db.apache.org/derby/docs/dev/devguide/rdevconcepts8424.html
> There is this section under single-row locks.
> -------------
> For TRANSACTION_READ_COMMITTED or TRANSACTION_REPEATABLE_READ isolation, Derby treats rows as cursors for SELECT statements. It locks rows only as the application steps through the rows in the result. The current row is locked.
> -------------
> The last statement above is not true for Repeatable read.  The last stmt needs to be changed to--
> For TRANSACTION_REPEATABLE_READ isolation, the locks are released at the end of the transaction. For TRANSACTION_READ_COMMITTED,  it locks rows only as the application steps through the rows in the result. The current row is locked. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Resolved: (DERBY-1683) Developer guide doc for scope of locks is incorrect for one case of repeatable read.

Posted by "Andrew McIntyre (JIRA)" <de...@db.apache.org>.
     [ http://issues.apache.org/jira/browse/DERBY-1683?page=all ]

Andrew McIntyre resolved DERBY-1683.
------------------------------------

    Fix Version/s: 10.2.1.5
                   10.3.0.0
                       (was: 10.2.2.0)
       Resolution: Fixed
       Derby Info:   (was: [Patch Available])

Committed 1683_2 patch to trunk with revision 451706.

> Developer guide doc for scope of locks is incorrect  for one case of repeatable read.
> -------------------------------------------------------------------------------------
>
>                 Key: DERBY-1683
>                 URL: http://issues.apache.org/jira/browse/DERBY-1683
>             Project: Derby
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 10.1.3.1, 10.1.3.0, 10.1.2.1, 10.1.1.0, 10.0.2.1, 10.0.2.0, 10.2.1.5
>            Reporter: Sunitha Kambhampati
>         Assigned To: Laura Stewart
>            Priority: Minor
>             Fix For: 10.2.1.5, 10.3.0.0
>
>         Attachments: derby1683.diff, derby1683_2.diff, rdevconcepts8424.html
>
>
> http://db.apache.org/derby/docs/dev/devguide/rdevconcepts8424.html
> There is this section under single-row locks.
> -------------
> For TRANSACTION_READ_COMMITTED or TRANSACTION_REPEATABLE_READ isolation, Derby treats rows as cursors for SELECT statements. It locks rows only as the application steps through the rows in the result. The current row is locked.
> -------------
> The last statement above is not true for Repeatable read.  The last stmt needs to be changed to--
> For TRANSACTION_REPEATABLE_READ isolation, the locks are released at the end of the transaction. For TRANSACTION_READ_COMMITTED,  it locks rows only as the application steps through the rows in the result. The current row is locked. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Updated: (DERBY-1683) Developer guide doc for scope of locks is incorrect for one case of repeatable read.

Posted by "Laura Stewart (JIRA)" <de...@db.apache.org>.
     [ http://issues.apache.org/jira/browse/DERBY-1683?page=all ]

Laura Stewart updated DERBY-1683:
---------------------------------

    Attachment: derby1683.diff
                rdevconcepts8424.html

Updated the dev guide topic per this issue. 
I also added several index entries and 
reformatted the topic so that there are now
"sections" with titles, which will make it easier to read
and locate information.

> Developer guide doc for scope of locks is incorrect  for one case of repeatable read.
> -------------------------------------------------------------------------------------
>
>                 Key: DERBY-1683
>                 URL: http://issues.apache.org/jira/browse/DERBY-1683
>             Project: Derby
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.5, 10.1.2.1, 10.1.3.0, 10.1.3.1
>            Reporter: Sunitha Kambhampati
>         Assigned To: Laura Stewart
>            Priority: Minor
>             Fix For: 10.2.2.0
>
>         Attachments: derby1683.diff, rdevconcepts8424.html
>
>
> http://db.apache.org/derby/docs/dev/devguide/rdevconcepts8424.html
> There is this section under single-row locks.
> -------------
> For TRANSACTION_READ_COMMITTED or TRANSACTION_REPEATABLE_READ isolation, Derby treats rows as cursors for SELECT statements. It locks rows only as the application steps through the rows in the result. The current row is locked.
> -------------
> The last statement above is not true for Repeatable read.  The last stmt needs to be changed to--
> For TRANSACTION_REPEATABLE_READ isolation, the locks are released at the end of the transaction. For TRANSACTION_READ_COMMITTED,  it locks rows only as the application steps through the rows in the result. The current row is locked. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Updated: (DERBY-1683) Developer guide doc for scope of locks is incorrect for one case of repeatable read.

Posted by "Laura Stewart (JIRA)" <de...@db.apache.org>.
     [ http://issues.apache.org/jira/browse/DERBY-1683?page=all ]

Laura Stewart updated DERBY-1683:
---------------------------------

    Attachment: derby1683_2.diff

Made an additional correction to the patch.


> Developer guide doc for scope of locks is incorrect  for one case of repeatable read.
> -------------------------------------------------------------------------------------
>
>                 Key: DERBY-1683
>                 URL: http://issues.apache.org/jira/browse/DERBY-1683
>             Project: Derby
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.5, 10.1.2.1, 10.1.3.0, 10.1.3.1
>            Reporter: Sunitha Kambhampati
>         Assigned To: Laura Stewart
>            Priority: Minor
>             Fix For: 10.2.2.0
>
>         Attachments: derby1683.diff, derby1683_2.diff, rdevconcepts8424.html
>
>
> http://db.apache.org/derby/docs/dev/devguide/rdevconcepts8424.html
> There is this section under single-row locks.
> -------------
> For TRANSACTION_READ_COMMITTED or TRANSACTION_REPEATABLE_READ isolation, Derby treats rows as cursors for SELECT statements. It locks rows only as the application steps through the rows in the result. The current row is locked.
> -------------
> The last statement above is not true for Repeatable read.  The last stmt needs to be changed to--
> For TRANSACTION_REPEATABLE_READ isolation, the locks are released at the end of the transaction. For TRANSACTION_READ_COMMITTED,  it locks rows only as the application steps through the rows in the result. The current row is locked. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Assigned: (DERBY-1683) Developer guide doc for scope of locks is incorrect for one case of repeatable read.

Posted by "Laura Stewart (JIRA)" <de...@db.apache.org>.
     [ http://issues.apache.org/jira/browse/DERBY-1683?page=all ]

Laura Stewart reassigned DERBY-1683:
------------------------------------

    Assignee: Laura Stewart

> Developer guide doc for scope of locks is incorrect  for one case of repeatable read.
> -------------------------------------------------------------------------------------
>
>                 Key: DERBY-1683
>                 URL: http://issues.apache.org/jira/browse/DERBY-1683
>             Project: Derby
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.5, 10.1.2.1, 10.1.3.0, 10.1.3.1
>            Reporter: Sunitha Kambhampati
>         Assigned To: Laura Stewart
>            Priority: Minor
>             Fix For: 10.2.2.0
>
>
> http://db.apache.org/derby/docs/dev/devguide/rdevconcepts8424.html
> There is this section under single-row locks.
> -------------
> For TRANSACTION_READ_COMMITTED or TRANSACTION_REPEATABLE_READ isolation, Derby treats rows as cursors for SELECT statements. It locks rows only as the application steps through the rows in the result. The current row is locked.
> -------------
> The last statement above is not true for Repeatable read.  The last stmt needs to be changed to--
> For TRANSACTION_REPEATABLE_READ isolation, the locks are released at the end of the transaction. For TRANSACTION_READ_COMMITTED,  it locks rows only as the application steps through the rows in the result. The current row is locked. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira