db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Segel <mse...@segel.com>
Subject Re: I need some advice to choose database for an upcomming job
Date Tue, 08 Nov 2005 19:18:08 GMT
On Tuesday 08 November 2005 08:50, Lance J. Andersen wrote:
> Daniel John Debrunner wrote:
> >Dag H. Wanvik wrote:
> >>Hi,
> >>
> >>>>>>>"Daniel" == Daniel John Debrunner <djd@debrunners.com>
wrote:
> >>
> >>Daniel>
> >>
> >>Daniel> I think there was a long discussion on this about six months ago,
> >> lead Daniel> by Phil Wilder. He was trying to clarify autocommit mode
> >> and held cursor Daniel> behaviour in the JDBC spec. It's a little
> >> unclear, as for example, Daniel> section 10.1 was not updated for held
> >> cursors. That was a case where the Daniel> wiki would have been useful,
> >> to present a summary of the current discussion. Daniel>
> >>Daniel> And as you say, I think that discussion was driven by differences
> >> in the Daniel> client and embedded drivers in this area.
> >>
> >>I talked to Lance about the spec being vague on this issue, and the
> >>new draft for JDBC 4.0
> >>(http://www.jcp.org/aboutJava/communityprocess/edr/jsr221/index2.html)
> >>
> >>has a new and clearer wording:
> >>>16.2.5 Closing a ResultSet Object
> >>>
> >>>A ResultSet object is explicitly closed when
> >>> - The close method on the ResultSet is executed, thereby releasing any
> >>>   external resources
> >>> - The Statement or Connection object that produced the ResultSet is
> >>>   explictly closed
> >>>
> >>>A ResultSet object is implicitly closed when
> >>> - The associated Statement object is re-executed
> >>> - The ResultSet is created with a Holdability of
> >>>   CLOSE_CURSORS_AT_COMMIT and an implicit or explicit commit occurs
> >>>
> >>>Note: Some JDBC driver implementations may also implicitly close the
> >>>ResultSet when the ResultSet type is TYPE_FORWARD_ONLY and the next
> >>>method of ResultSet returns false.
> >>
> >>Note that executing a statement on *another* statement object in the
> >>same connection no longer closes a result set,
>
> This has never been the intent in JDBC since its inception,  From the
> 1.0.2 spec:
>
> Multi-threading
> We require that all operations on all the java.sql objects be
> multi-thread safe and able to cope
> correctly with having several threads simultaneously calling the same
> object.
> Some drivers may allow more concurrent execution than others. Developers
> can assume fully
> concurrent execution; if the driver requires some form of
> synchronization, it will provide it.
> The only difference visible to the developer will be that applications
> will run with reduced concurrency.
> For example, two Statements on the same Connection can be executed
> concurrently and their
> ResultSets can be processed concurrently (from the perspective of the
> developer). Some drivers
> will provide this full concurrency. Others may execute one statement and
> wait until it completes
> before sending the next.
>
>
> HTH
>
> -lance
>

Geez, 
I guess I should have quoted from the spec, rather than the first JDBC 
tutorial, in which the author's did quote exactly that.

This is not to say that junior is wrong. I do believe him that the 3.0 spec 
probably does say that. 

This is a problem that occurs when people don't think about their design and 
merely regurgitate what they've read. Or that they rush a design without 
thinking about it first.

As pointed out, JDBC 4.0 spec does seem to correct this.

But hey, what do I know. I'm not paid to play here. ;-)

-G


-- 
Michael Segel
Principal 
MSCC

Mime
View raw message