db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5960) VirtualRandomAccessFile.close() is not idempotent
Date Wed, 24 Oct 2012 11:58:11 GMT

     [ 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

Mime
View raw message