Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dtp-connect-dev] Reduce the Derby connection reference

Hi Max,

> exerpt from the Derby developer's guide:
> Getting a nested connection
> When you are executing a method within SQL, that method might need
> to reuse the
> current connection to the database in order to execute more SQL
> statements. Such a
> connection is called a nested connection. The way for a method to get a
nested
> connection is to issue a connection request using the connection URL.
> jdbc:default:connection
> URL attributes are not supported as part of this connection URL. Any
> URL attributes
> specified in a Properties object, user name, or password that are passed
to a
> java.sql.DriverManager.getConnection() call will be ignored.
>
> I haven't investigated into this problem thoroughly, but I feel this
> might be an alternative way to tackle the "single connection per vm"
> problem.

>From the research I have done, the nested connection is intended to be used
within Java stored procedures where the stored procedure needs to execute
SQL within the transaction space of the calling connection (
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200505.mbox/%3C42826A36.1080602@xxxxxxxxxxxxxx%3E)
.

Given that embedded Derby's methods for connection management diverge from
those of most JDBC drivers and that there is a ready workaround (using it
as a network server), I don't feel that it is worth the effort to keep
hacking at this.

> If we go this way, then I can just compare the newly
> created connection with the shared connection to see whether they
> are the same and whether I should close it. What do you think?

I'm curious, why are you comparing connections with the shared connection
managed by the profile?  Do you have your own connection management
implementation?  The planned method of integration was to use the shared
connection on the profile for all read-only operations.  If a write
operation needed to be performed, the consumer should either create a new
connection using a connection factory or use the cloneConnection() method
on the IManagedConnection.

Regards,
Rob



Back to the top