-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 6 posts ] 
Author Message
 Post subject: JDBC Statements and access to connection pool
PostPosted: Sun Sep 28, 2003 7:04 pm 
Newbie

Joined: Mon Sep 08, 2003 5:47 pm
Posts: 9
Location: Denver
I've just moved an application from Apple's Enterprise Objects to Hibernate. I'm very pleased so far.

99% of the app is using the ORM facilities. However, I have one class that needs to create and populate a table. That is, I'd like to use java.sql.Statement.executeUpdate() to create the table and then perform inserts.

1) Is there some alternative Hibernate API that accomdates raw JDBC calls? (esp. DDL statements)

2) If not, is there hibernate API that would allow me to check out a connection from Hibernate's connection pool?

3) Or, do I need to set up a separate connection pooling mechanism for this one method?

4) In order to configure pooling only once, should I not take advantage of the pooling abstraction in Hibernate, use an external pooling API and pass connections to Hibernate's SessionFactory?

Note: I tried creating a Session and then using its Connection but got "aborted transaction" exceptions (even after calling connection().commit()). It seemed an unwise approach as I don't know what Hibernate does to the connection.

Thanks!,
- Chris


Top
 Profile  
 
 Post subject:
PostPosted: Sun Sep 28, 2003 7:06 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 12:50 pm
Posts: 5130
Location: Melbourne, Australia
Session.connection() ?


Top
 Profile  
 
 Post subject: Tried that
PostPosted: Fri Oct 03, 2003 12:37 am 
Newbie

Joined: Mon Sep 08, 2003 5:47 pm
Posts: 9
Location: Denver
>Note: I tried creating a Session and then using its Connection (with
>session.connection()) but got "aborted transaction" exceptions (even
>after calling session.connection().commit()). It seemed an unwise
>approach as I don't know what Hibernate does to the connection.

Is there a proper way to use a Session's connection with java.sql.Statments? Do I need to worry about the Transaction API?

For the moment I'm using a second connection pool. I would very much prefer to have only one.

Thanks,
- Chris


Top
 Profile  
 
 Post subject:
PostPosted: Fri Oct 03, 2003 6:59 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 7:19 pm
Posts: 2364
Location: Brisbane, Australia
Use it exactly the way you would for hibernate persisent object just for JDBC get the connection and perform your operation(s). It will still be wrapped by the same transaction and sundry code.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 13, 2003 4:44 am 
Newbie

Joined: Mon Sep 08, 2003 5:47 pm
Posts: 9
Location: Denver
Any idea why I'm getting "Transaction Aborted" messages with code like the following:
Code:
Session session; // assume exists
Connection myConnection = session.getConnection();
Statement st = myConnection.createStatement();
st.executeUpdate("create table foobar (...)");
myConnection.commit();


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 13, 2003 8:20 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 7:19 pm
Posts: 2364
Location: Brisbane, Australia
Use the hibernate API for transaction and session manage, ie, only get the connection from the session and do your basic JDBC operations. Other than the data access JDBC operation treat it just as if you are using the hibernate API.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 6 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.