Hi Craig,
I am using the extended persistence context paradigm and I have configured
Spring Framework's transactions to use
org.springframework.orm.jpa.JpaTransactionManager
I inject the EntityManagerFactory into the JpaTransactionManager after grabbing
an EntityManager and storing it in a t
Hi Adam,
Sorry it took so long to get back to you. According to Matthew Adams,
when using Spring:
See method retrieveTransactionSynchronizationRegistry() for the
particular JtaTransactionManager subclass that you are using; it's
protected in JtaTransactionManager, and subclasses (like
W
Patrick Linskey on 10/11/07 21:15, wrote:
Without anyone else's input on this, I'm going to look further down this route:
providing OpenJPA with the means to get at the managed transactions / entity
managers.
Do you know whether this is OpenJPA functionality only or if it's specified in
the EJB
OK, but presumably nowhere in the JTA spec does it state that it should be able
to function outside an EJB container, in the way that JPA does?
[EMAIL PROTECTED] on 14/11/07 01:30, wrote:
They're both part of the JTA spec.
-Patrick
On 11/13/07, Adam Hardy <[EMAIL PROTECTED]> wrote:
Patrick L
They're both part of the JTA spec.
-Patrick
On 11/13/07, Adam Hardy <[EMAIL PROTECTED]> wrote:
> Patrick Linskey on 10/11/07 21:15, wrote:
> > Hi,
> >
> >> if openjpa.TransactionMode=local, we have to deal with the transactions
> in the
> >> data access layer. But this is not what I want to do -
Patrick Linskey on 10/11/07 21:15, wrote:
Hi,
if openjpa.TransactionMode=local, we have to deal with the transactions in the
data access layer. But this is not what I want to do - I'd like my 'non-EJB
transaction manager of choice' (currently Spring) to manage them.
There are a few different
> No, I'd rather keep Spring away from managing the persistence unit. There's
> alot
> I want to be able to do with it that doesn't fit in with the way Spring
> handles
> it. The DAO abstract superclass from Spring is quite restrictive, and combined
> with the testing, it sucks the unwary into co
Patrick Linskey on 10/11/07 21:15, wrote:
if openjpa.TransactionMode=local, we have to deal with the transactions in the
data access layer. But this is not what I want to do - I'd like my 'non-EJB
transaction manager of choice' (currently Spring) to manage them.
There are a few different concep
Hi,
> if openjpa.TransactionMode=local, we have to deal with the transactions in the
> data access layer. But this is not what I want to do - I'd like my 'non-EJB
> transaction manager of choice' (currently Spring) to manage them.
There are a few different concepts at play here. One is the
transa
So I'm not the only one then.
I just hit another issue at the data access layer/DAOs. According to the OpenJPA
docs, the idiomatic design for the data access layer is to use an injectable
Entity Manager Factory which provides a fresh Entity Manager each time.
if openjpa.TransactionMode=local,
Adam,
I'm interested in this as well, I'm trying to build a Struts2 app to
be distributed that provides a "best-practices" example of JPA in
struts2 (a refactoring of the struts-mailreader for those who are
familiar with it). I want to keep Spring out, so I was thinking of
adapting the OpenSession
I need transactions in my webapp using the OpenSessionInView filter pattern to
enable use of entities in my JSPs.
I am not using an EJB3 container, and I am restricting my use of Spring, or at
least trying to, to the IoC and transaction manager (for XML transaction
configuration).
Is there a
12 matches
Mail list logo