| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| JDBC and a JPA provider (like Hibernate) |
« View previous topic :: View next topic » |
| Author |
Message
|
| darioo |
 Posted: Sat Oct 27, 2012 4:56 am Post subject: JDBC and a JPA provider (like Hibernate) |
 |
|
Novice
Joined: 19 Mar 2009
Posts: 15
|
Has anybody tried (and had success) with configuring Message Broker to use a JPA (Java Persistence API) provider in JavaCompute nodes? One of the main issues I see with using a JPA provider is the fact that WMB provides its own mechanisms for transaction handling, connection pooling etc. which aren't necessarily compatible with the way regular Java SE or Java EE applications work when dealing with database connectivity.
For example, we aren't allowed to include code that uses commit or rollback statements, closes database connections etc.
I've read this part:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fac30494_.htm&path=1_7_7_2_1_5
Yes, I know about ODBC connections and have used them with ESQL with great success.
Yes, I know that WMB shouldn't be used like an application server.
But still, there exist some cases when using an ORM would be more practical than coding plain JDBC statements.
Why am I researching this and not simply using ESQL? Because we've had some cases of Oracle ODBC drivers blowing up on us - calling stored procedures with BLOB parameters getting mangled and truncated to 0 byte inputs; not very pretty... although we did find some workarounds, there exists an incentive to migrate all database code from ODBC to JDBC. This might not really happen, but I have to think and plan proactively.
Right now we're using WMB 7.0.0.2. These issues might have been fixed in newer releases, but right now we're stuck with this version and we'll see when we'll be able to migrate to WMB 8.0.0.1, for example. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Sat Oct 27, 2012 7:35 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So, I believe some careful reading will illustrate that one is not suposed to use commit/rollback with connections acquired from getJDBCType4Provider, and that it's not a general prohibition.
You should be able to stuff an entire WAS application client into a JCN and happily pretend you live in a world that doesn't include Broker administrators who have more important things to do than baby your message flow.
I do realize and comprehend that you're not discussing things that drastic.
I'm just saying that I believe things are more flexible than you're reading, but that all things have consequences. The act of IT is the art of balancing the requirement against the consequence - and that's part of why you're looking at JPA... |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Oct 27, 2012 8:20 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I believe JPA will service you better if you dump the DB part into a queue that you service via an MDB... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Oct 27, 2012 8:54 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Also, I believe even at 7.0.0.2 there was a mechanism to use a newer level of the ODBC drivers than shipped with the base product.... but it's a half-memory, so it's best to double-check it against reality. |
|
| Back to top |
|
|
| xzhou |
| Posted: Tue Oct 30, 2012 1:48 pm Post subject: |
|
|
Apprentice
Joined: 11 Apr 2008
Posts: 32
|
The following is from IBM.
| Quote: |
| Use the broker Java API getJDBCType4Connection to initiate the connection, then perform SQL operations by using the standard JDBC APIs. The broker manages the connections, thread affinity, connection pooling, and lifecycle. |
A JPA provider needs control the transaction in most of cases, it will automatically flush data into DB in certain cases. I doubt you could move your non-trivial application using JPA into WMB in most of cases. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 31, 2012 5:05 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| xzhou wrote: |
The following is from IBM.
| Quote: |
| Use the broker Java API getJDBCType4Connection to initiate the connection, then perform SQL operations by using the standard JDBC APIs. The broker manages the connections, thread affinity, connection pooling, and lifecycle. |
A JPA provider needs control the transaction in most of cases, it will automatically flush data into DB in certain cases. I doubt you could move your non-trivial application using JPA into WMB in most of cases. |
The same link mentioned above by darioo also says
| Quote: |
JDBC API in an unmanaged environment
You can access standard Java APIs in the code that you write for your JavaCompute nodes, including JDBC calls. You can therefore use JDBC APIs to connect to a database, write to or read from the database, and disconnect from the database. On operating systems other than z/OS, the broker supports your JDBC connection code calling both type 2 and type 4 JDBC drivers in this environment, but does not supply them. You must obtain these drivers from your database vendor. On z/OS, type 2 drivers are not supported.
If you choose this method to access databases, the broker does not support managing the transactions; your code must manage the local commit and rollback of database changes. Your code must also manage the connection lifecycle, connection thread affinity, and connection pooling. You must also monitor the access to databases when you use this technique to ensure that these connections do not cause interference with connections made by the broker. In particular, be aware that type 2 drivers bridge to an ODBC connection that might be in use in message flows that access databases from ESQL. |
So, yes, you should perfectly well be able to use JPA from within a JCN.
It's just a heavy weight solution and ignores a lot of the function that broker provides and will not work in harmony with the rest of the message flow, without effort from the developer. |
|
| Back to top |
|
|
| MikeOliverAZ |
| Posted: Thu Aug 22, 2013 11:01 pm Post subject: What if Hibernate is not transactional |
|
|
Apprentice
Joined: 10 Jul 2013
Posts: 47
|
Very interesting thread. We have a situation with an existing records management application that uses Hibernate/JPA and Oracle. The relations between objects is such that we would much rather use the existing Hibernate to fetch the object tree than to try to recreate that tree in sql, not that it couldn't be done. We are NOT updating or creating records, just finding the nodes and hibernate, jpa and Spring classes already do all that work with an entity finder method....why re-invent an 18 wheeler when an existing class has a single mathod that does what we need. And the objects it retrieves have methods we can use as well such as validation and filters...so
We very much want to use Hibernate from our Java Compute Node fetch the objects we want and move on. In fact most of the time the objects we want should be in the L2 cache.
so we have the required jars in the java build path in the java project, all compiles well.
Only problem now is the database.properties file, where to put it so it gets read? |
|
| Back to top |
|
|
| darioo |
| Posted: Fri Aug 23, 2013 1:47 am Post subject: |
|
|
Novice
Joined: 19 Mar 2009
Posts: 15
|
You could put database.properties somewhere in your project's classpath (where your Java files are), but I doubt this is the right way. After all, you're going to hardcode username and password of your database, unless you do some processing trickery afterwards.
Not only that, but you're obtaining a DB connection outside of WMB's control and I don't think that bodes well for transactions, rollbacks, connection caching, basically everything WMB does automatically.
I haven't tried integrating JPA with WMB; we went the DB mapping node route and it worked well for our project.
If I were to really go that route and use Hibernate, my suggestion would be to read Hibernate documentation and see whether it's possible to tell Hibernate how to obtain WMB provided JDBC connection using getJDBCType4Connection since it would be the most "natural" thing to do.
This would require implementing certain interface(s) and also keeping in mind that Hibernate should not close WMB's connection at any time. Low level housekeeping.
Note that I haven't actually tried or read about anything I've mentioned in last two paragraphs, so I'm not claiming that it's even possible. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 23, 2013 6:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Presumably you would use a JavaClassLoader Configurable Service and place the properties file in the relevant class loader directory. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
You cannot vote in polls in this forum
|
|
|
|
