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 "Knut Anders Hatlen (JIRA)" <ji...@apache.org> on 2012/10/24 13:58:11 UTC

[jira] [Updated] (DERBY-5960) VirtualRandomAccessFile.close() is not idempotent

     [ https://issues.apache.org/jira/browse/DERBY-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Knut Anders Hatlen updated DERBY-5960:
--------------------------------------

    Attachment: d5960-1a.diff

Attaching a fix, including a test case in VirtualFileTest.

The patch simply makes close() stop nulling out the fields so that it won't run into a NPE on subsequent executions.

(I preferred that approach to adding extra null checks in close(), as it allows the code to be slightly shorter/simpler. The advantage of nulling the fields and adding extra checks would be that the objects references by the fields would be eligible for gc earlier if the VirtualRandomAccessFile instance itself was still referenced after close(). I believe that this is not the case in normal use of VRAF. And even if it is used that way, there's not much to gain since the big data structures (the byte arrays) in those instances are already freed. So adding extra code to optimize for that case didn't seem worthwhile.)

I also used the opportunity to fix a typo in VirtualFile and make some of the fields in VirtualRandomAccessFile final.

All the regression tests ran cleanly with the patch.
                
> VirtualRandomAccessFile.close() is not idempotent
> -------------------------------------------------
>
>                 Key: DERBY-5960
>                 URL: https://issues.apache.org/jira/browse/DERBY-5960
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.10.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: d5960-1a.diff
>
>
> If VirtualRandomAccessFile.close() is called more than once, which might happen in code that cleans up after errors, it will throw a NullPointerException. We should make close() idempotent so that it is more robust.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira