I would add some (obvious ? if yes, sorry) things :
0. Yes, you're playing with fire, but that's really fun and very powerful as
long as you don't start a forest fire :-)
1. Ensure connection is at last closed or put back in the pool.
2. Test with and without a pool (or adjust value on pool) to force connection
to be reused so you can test the code will have a long peaceful life on server.
3. heavy use of try {} finally{} block to ensure the flow control even in case
of error in the other side.
4. Use of ThreadLocal may lead to memory leak, ensure connection is not only
closed (1) but also remove from ThreadLocal at the end
On 19 oct. 2010, at 15:40, Kevin Sutter wrote:
> Hi Daryl,
> You might be playing with fire, but if nobody gets hurt... :-) Seriously,
> as I was reading through your scenario, my first thought was to use Read
> Uncommitted isolation level. Not sure how this might affect your other
> database transactions, but this seems to be the scenario you are
> describing. You want your EM query to pick up the uncommitted changes on
> your JDBC connection. Have you tried adjusting the isolation level?
>
> If that won't work, then doing your hack of overriding the close() method is
> probably okay. Especially since your EM interactions are just queries. You
> don't mention when your transactions commit for either JDBC or JPA, so I'm
> not completely clear on how overriding the close() allows the EM to see your
> JDBC updates.
>
> I'm also assuming that you are not using any type of connection pooling,
> right? This sounds like a simple "migration" application that is not
> looking to scale, so just utilizing a single connection should be
> sufficient.
>
> Good luck,
> Kevin
>
> On Mon, Oct 18, 2010 at 1:41 PM, Daryl Stultz <da...@6degrees.com> wrote:
>
>> Hello all,
>>
>> A while back I asked if there was a way to share a connection between my
>> JDBC code and JPA code. It was suggested that I open an transaction on the
>> EM and then access the connection on the transaction. I'm sure this will
>> work, but I need to do the opposite.
>>
>> I have a code block that gets a JDBC connection, loops over some things and
>> performs actions on one transaction per loop. In each loop some JPA action
>> may take place on an EM. The problem is that the JDBC connection is in a
>> transaction, and the queries run from the EM don't see the newly inserted
>> records.
>>
>> I happen to be using a DataSource to supply OpenJPA with connections. The
>> JDBC connection is available via a ThreadLocal variable (as is one and only
>> one EM). I did a quick test where my DataSource simply provides a wrapper
>> of
>> the JDBC connection. I override the close() method to do nothing so the
>> outer JDBC code is not killed. It works. The EM queries are performed on
>> the
>> same JDBC connection. Naturally, I do not expect OpenJPA to "join" the JDBC
>> connection, nor do I expect to need to open a transaction on the EM in the
>> loop. (Interestingly, though, it does not crash when I do so.)
>>
>> So given my simple test seems to work, I'm wondering if anyone can tell me
>> if I'll run into some major trouble later. Am I playing with fire?
>> Ultimately this is "transition" code from JDBC to JPA, but it may be around
>> for a while.
>>
>> Thanks.
>>
>>
>> --
>> Daryl Stultz
>> _____________________________________
>> 6 Degrees Software and Consulting, Inc.
>> http://www.6degrees.com
>> http://www.opentempo.com
>> mailto:daryl.stu...@opentempo.com
>>
