back to listing index

Can I access current thread-local java.sql.Connection? - Google Groups

[web search]
Original source (groups.google.com)
Clipped on: 2013-02-01

Can I access current thread-local java.sql.Connection?
4 posts by 2 authors in Squeryl
Image (Asset 1/1) alt=managed by Squeryl, to avoid passing it as extra argument. Is Subj
possible?

Dmitry Grigoriev
Join group to reply
3/21/10
In fact, this is the use case I need quite often when working with
databases of dynamic structure. For example, consider some sort of
hierarchical catalog where admin can configure structure (visible
properties list) of each category. This obviously requires executing
ALTER TABLE along with editing category metadata, in the same
transaction. So the problem is much deeper than just setting up and
passing around another connection for DDL.

So could you please add some static method like
Session.currentConnection(): java.sql.Connection, which would throw if
outside transaction? I need this one urgently. :(

Max
Join group to reply
3/21/10

 You can do this already with

  Session.currentConnection.connection

Regarding altering the schema within a transaction, some
databases perform a commit of the current transaction
when any DML is invoked (ok, I'm talking of oracle, ... it could be the only
one doing this !;-))

 So you *might* want to do this in a dedicated transaction
(simply be wrapping the DML inside a transaction {} block),
as opposed to using the current one.

 Cheers


- show quoted text -
- show quoted text -

To unsubscribe from this group, send email to squeryl+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Dmitry Grigoriev
Join group to reply
3/21/10

>  You can do this already with
>
>   Session.currentConnection.connection
Great, thanks! :)

> Regarding altering the schema within a transaction, some
> databases perform a commit of the current transaction
> when any DML is invoked (ok, I'm talking of oracle, ... it could be
> the only
> one doing this !;-))
>
>  So you *might* want to do this in a dedicated transaction
> (simply be wrapping the DML inside a transaction {} block),
> as opposed to using the current one.
Nooo... This time I meant exactly what I said. In the example I
explained, both "update category_metadata where id=N" and "alter table
category_N" form a single atomic logical operation.

BTW, it's a great benefit of PostgreSQL that it correctly logs DDL
operations along with DML. Besides my current concern, this allows
complex automatic database schema upgrades without the need to manually
backup it first and manually restore backup if update fails... I don't
know anything about Oracle, but I know how terrible and dangreous MySQL
is (or was) about DDLs in transactions.

>  Cheers
Yeah, 2 you too. :)