Re: COPY using Hibernate

you can just check out the inner Connection with c3p0's reflective
API, if you want. the preachiness is a speedbump, but nothing prevents
you from returning RAW_CONNECTION_OBJECT. just be sure that when
you're done, the you've not left the state of the Connection modified,
cuz that can lead to subtle misbehavior.

~oo~
Steve Waldman
swaldman(at)mchange(dot)com

On Jan 15, 2010, at 7:59 AM, Craig Ringer
<craig(at)postnewspapers(dot)com(dot)au> wrote:

> On 15/01/2010 8:00 PM, Dave Cramer wrote:
>> Hi Vaibhav
>>
>> C3p0 provides a mechanism to get at the underlying connection and
>> statement. search for c3P0 underlying connection
>
> According to the C3P0 docs:
>
> "JDBC drivers sometimes define vendor-specific, non-standard API on
> Connection and Statement implementations. C3P0 wraps these Objects
> behind a proxies, so you cannot cast C3P0-returned Connections or
> Statements to the vendor-specific implementation classes. C3P0 does
> not provide any means of accessing the raw Connections and
> Statements directly, because C3P0 needs to keep track of Statements
> and ResultSets created in order to prevent resource leaks and pool
> corruption."
>
> ... so, you can't just get the connection from your Hibernate
> Session and use that. Instead, you have to do it reflectively via
> C3P0 methods:
>
> "C3P0 does provide an API that allows you to invoke non-standard
> methods
> reflectively on an underlying Connection. To use it, first cast the
> returned Connection to a C3P0ProxyConnection. Then call the method
> rawConnectionOperation, supplying the java.lang.reflect.Method object
> for the non-standard method you wish to call as an argument. The
> Method
> you supply will be invoked on the target you provide on the second
> argument (null for static methods), and using the arguments you supply
> in the third argument to that function. For the target, and for any of
> the method arguments, you can supply the special token
> C3P0ProxyConnection.RAW_CONNECTION, which will be replaced with the
> underlying vendor-specific Connection object before the Method is
> invoked."
>
> See:
> http://www.mchange.com/projects/c3p0/index.html#raw_connection_ops
>
>
> Permit me to say "argh!". It's highly frustrating that you can't
> just "check out" a connection, unwrapping it and taking
> responsibility for any statements and result sets you create while
> it's unwrapped.
>
> ( C3P0's documentation is really preachy about this, and likes to
> explain to you how you shouldn't want to do "legacy" things like
> that since it breaks "database independence" which is apparently
> something it's unthinkable not to care about for your particular
> app ... sigh. )
>
> In my J2SE app I only need one connection for the app - and in fact
> it's strongly preferable to limit the app to one connection. I also
> needed direct access to that connection to use listen/notify via
> PgConnection. Hibernate wants you to use a connection pool, and
> jealously guards the connections it obtains via the pool - in fact,
> if you're using Hibernate via JPA2 you can't access the underlying
> JDBC connection *at* *all*.
>
> Thankfully Hibernate provides a clean and simple abstraction for its
> access to connection pools, so I landed up writing my own
> SingleConnectionProvider to give Hibernate its "pool" of one
> connection. The provider blocks on any getConnection(...) requests
> issued while the connection is checked out to someone else, so I can
> just check the connection out of the pool directly if I want to do
> PostgreSQL-specific things with it ( like using listen/notify or
> COPY ) and use Hibernate the rest of the time. It works great. If
> it'd be of any use to you, let me know.
>
> --
> Craig Ringer
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc