On Apr 24, 2007, at 11:38 AM, Marc Prud'hommeaux wrote:
David-
Does this seem like a reasonable explanation?
That sounds right to me.
Note that if we ever update OpenJPA to depend solely on the
TransactionSynchronizationRegistry, then we won't be able to do
things like suspending the
That's why we have two datasources for an EMF. One is the
transactional datasource that gives you connections
automatically enlisted in your transactional EM; the other
gives you connections that are never enlisted and can be used
for nontransactional queries, nontransactional sequences
On 4/24/07, Patrick Linskey [EMAIL PROTECTED] wrote:
Can you ask the websphere team to support a Callable also, so
we can easily return a value or throw an exception from the
task?
Seems like for WAS's needs, just supporting Callable would be good
enough, no?
Unfortunately, I am just the
Hi Partick,
On Apr 25, 2007, at 11:41 AM, Patrick Linskey wrote:
That's why we have two datasources for an EMF. One is the
transactional datasource that gives you connections
automatically enlisted in your transactional EM; the other
gives you connections that are never enlisted and can be
If everyone has extra functionality why is it so hard to
come to a common set of features? There's no intrinsic value
in one app server giving access via Proprietary Interface 1
and another app server giving the same access via Proprietary
Interface 2.
I think that the issue at the time
suspend/resume) and it has recently provided the means to
execute a Runnable in a new Tx (via the runUnderUOW feature)
Yay!
It should be very easy to restructure our existing code to move the
relevant logic to a Runnable.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
Can you ask the websphere team to support a Callable also, so
we can easily return a value or throw an exception from the
task?
Seems like for WAS's needs, just supporting Callable would be good
enough, no?
We need to use Runnable at the end of the day in ManagedRuntime, so that
things