Using CDI / JPA with an ApplicationScoped bean

[Jonathan Laterreur]

Hi,

Can we use something like this with thorntail ?

@Named
@ApplicationScoped
@Transactional
public class AuthServiceBean extends AbstractService implements AuthService {
    private static final Logger LOGGER = LoggerFactory.getLogger(AuthServiceBean.class);

    @PersistenceContext
    protected EntityManager em;

I mean, an applicationScoped in a multi-thread environment.

I know that with Wildfly, there's is a TransactionScopedEntityManager that seem to work in a singleton bean (the entitymanager is scoped with a transaction).

Thanks!

[kg6zvp]

If you're asking about v4, then I think the answer is no, it does not incorporate those pieces of Wildfly.

I believe v2 does, though, as it is essentially embedded Wildfly 11 with some other bits glued on.

[Ken Finnigan]

If I recall correctly @Named is JSF right?

If so, I think that’s the only piece that wouldn’t be there with v4. Everything else should work. If it doesn’t, then it’s probably a bug

Ken

[kg6zvp]

@Ken: Thanks for the authoritative answer.

I didn't see the transaction management code he mentioned in his question in the v4 code. Is Thorntail bringing in a dependency transitively that manages those transactions in the way the OP described?

[Jonathan Laterreur]

@Named comes with javax.inject. It's a String-based qualifier. It's not important for my question (sorry).

@kg6zvp

This is what I found in v4 : https://github.com/thorntail/thorntail/blob/4.x/core/jpa/src/main/java/io/thorntail/jpa/impl/EntityManagerProducer.java

I don't think it manage the transaction-scoped entitymanager (thread safe).

[Jonathan Laterreur]

For reference : https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/java/org/jboss/as/jpa/container/TransactionScopedEntityManager.java

[kg6zvp]

@jonathan: To clarify, if the code you posted originally (with `@PersistenceContext`) is what you're using then the EntityManagerProducer is not used. It instead relies on the `JpaServices` class which implements a CDI service for resolving such references. It's a bit confusing given that Thorntail is using non-standard behavior to accommodate the lack of EJB support while still allowing JPA to be used conveniently.

Is this link similar to what you're referring to? https://stackoverflow.com/q/24643863/1024412

[Bob McWhirter]

EntityManagerProducer was created prior to us understanding the JpaServices. Perhaps we should now remove the former to avoid confusion?

Bob

On Sun, May 13, 2018 at 11:48 PM kg6zvp <kg6...@gmail.com> wrote:

@jonathan: To clarify, if the code you posted originally (with `@PersistenceContext`) is what you're using then the EntityManagerProducer is not used. It instead relies on the `JpaServices` class which implements a CDI service for resolving such references. It's a bit confusing given that Thorntail is using non-standard behavior to accommodate the lack of EJB support while still allowing JPA to be used conveniently.

Is this link similar to what you're referring to? https://stackoverflow.com/q/24643863/1024412

--
You received this message because you are subscribed to the Google Groups "Thorntail" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thorntail+...@googlegroups.com.
To post to this group, send email to thor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/thorntail/214b9e05-2c6f-4863-94fe-307dbca3ec24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[kg6zvp]

@bob: I agree.

To be safe, is there any reason we should keep EntityManagerProducer and it's ilk?

[Martin Kouba]

Dne 13.5.2018 v 22:43 Jonathan Laterreur napsal(a):

> Hi,
>
> Can we use something like this with thorntail ?
>
> @Named
> @ApplicationScoped
> @Transactional
> public class AuthServiceBeanextends AbstractServiceimplements AuthService {
> private static final LoggerLOGGER = LoggerFactory.getLogger(AuthServiceBean.class);
>
> @PersistenceContext
> protected EntityManagerem;
>
>
> I mean, an applicationScoped in a multi-thread environment.

In general, @ApplicationScoped CDI beans can be used concurrently but
you must ensure the thread-safety, e.g. using synchronization or
constructs from java.util.concurrent package.

In general, EntityManager is not guaranteed to be thread safe:
"An entity manager must not be shared among multiple concurrently
executing threads, as the entity manager and persistence context are not
required to be threadsafe. Entity managers must only be accessed in a
single-threaded manner." (JPA 2.1, 7.2 Obtaining an EntityManager)

On the other hand, TransactionScopedEntityManager seems to work as a
proxy for the underlying EntityManager, automatically joining the active
transaction if present. And Swarm leverages WildFly's JPA subsystem so I
believe your snippet is OK.

Of course, I'm no JPA expert ;-)

>
> I know that with Wildfly, there's is a TransactionScopedEntityManager
> that seem to work in a singleton bean (the entitymanager is scoped with
> a transaction).
>
> Thanks!
>

> --
> You received this message because you are subscribed to the Google
> Groups "Thorntail" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to thorntail+...@googlegroups.com

> <mailto:thorntail+...@googlegroups.com>.

> To post to this group, send email to thor...@googlegroups.com

> <mailto:thor...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/thorntail/c8698246-1ee2-4c5d-af8f-1215904aa3b0%40googlegroups.com
> <https://groups.google.com/d/msgid/thorntail/c8698246-1ee2-4c5d-af8f-1215904aa3b0%40googlegroups.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.

--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

[Bob McWhirter]

If @PersistenceContext is the more correct and normal answer I’d say we should remove EMP.  EMP will break with multiple PUs also right?

Bob

On Mon, May 14, 2018 at 6:38 AM kg6zvp <kg6...@gmail.com> wrote:

@bob: I agree.

To be safe, is there any reason we should keep EntityManagerProducer and it's ilk?

--
You received this message because you are subscribed to the Google Groups "Thorntail" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thorntail+...@googlegroups.com.
To post to this group, send email to thor...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/thorntail/f7ae09a4-5ca2-4713-8f2f-1dcb1220c1c6%40googlegroups.com.

[Jonathan Laterreur]

Yes you're right with Swarm but I'm not sure it's the case with Thorntail.

It would be pretty nice to have the same behavior of Wildfly with Thorntail. Otherwise, people that come from Wildfly with have some surprise.

The other way is to use @TransactionScoped https://docs.oracle.com/javaee/7/api/javax/transaction/TransactionScoped.html

I don't tested it and I don't like the fact that it create a new instance for each transaction. I mean, a service should a singleton in my mind.

[kg6zvp]

I agree on this. It seems like the closer we can get Thorntail v4's behavior to standard JavaEE application servers, the better.

Should I create a PR removing the @Inject functionality from v4?

[Bob McWhirter]

I’d say yes. Plus appropriate docs changes if you’re feeling frisky. 

Bob

To unsubscribe from this group and stop receiving emails from it, send an email to thorntail+...@googlegroups.com.
To post to this group, send email to thor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/thorntail/7c141c97-a1a3-4ac8-9c52-1f6303131516%40googlegroups.com.

[kg6zvp]

@Bob: Docs are important. :) I'll get on it.