Bug 5760

Summary: Spec should clarify that reader/write close() get called after exceptions
Product: jbatch Reporter: ScottKurz
Component: SPECAssignee: ScottKurz
Status: NEW ---    
Severity: minor CC: issues
Priority: P5    
Version: 1   
Target Milestone: ---   
Hardware: All   
OS: All   

Description ScottKurz 2014-01-31 16:07:19 UTC

Comment 1 ScottKurz 2014-02-05 15:19:38 UTC
Added 'future' to whiteboard to consider idea of extending Closeable in a future release.
Comment 2 ScottKurz 2014-02-13 13:12:33 UTC
Not committing to address in future, just listing as candidates and pointing out they're excluded from current Maintenance Rel.
Comment 3 ScottKurz 2014-10-07 10:49:31 UTC
As I'm looking back on this now I'm realizing that I got too hung up on the idea that it was too late to start implementing Closeable (with idempotent close()).   We could have still considered saying this was the required behavior even without the interface to enforce this further.

For what it's worth, I'm almost positive the RI may call close() twice in some cases, for example if the writer close() throws an exception on certain paths we might retry to close both reader and writer.

Noticing this in walking through my fix for Bug 6259.
Comment 4 ScottKurz 2016-06-20 20:47:36 UTC
Another thing to clarify:  the diagrams in Section 11, showing reader and writer close() in a single transaction, could lead to some confusion.  E.g. if the writer close() throws an exception, and the tran rolls back, what does this mean for the reader?  Do we still call reader close()?  In what transaction?

This should be clarified.  Note that there are now several close()-related issues open (e.g. Bug 6456, Bug 7684) and it might make sense to tackle them together instead of via the current breakdown.