Re: [jakartaee-platform-dev] Deprecate JSR-352 and rework JSR-236

[Tibor Digana <tibordigana@xxxxxxxxxx>]

You have EntityManager CDI producer, and you cannot inject it in the Batch beans of Reader/Processor/Writer. The JBoss still considers these beans as EJB.

You cannot use transactions of CDI in the listeners because there is no Context available and you need to have it because you want to update the state in the state machine.

You want to inject CDI beans but @Inject is not allowed. We do not want to use EJB.

You want to use scoped beans but this API does not know what scope means.

So the workaround is to inject EJB beans and make Async calls in order to use the transactions in the leaf.

Even if you try to use @Transactional in the Processor bean, the JBoss will crash because Arjuna is using it together with the Request scope but this cope is unknown in Batch.

As I told you this is really SE style of design and the beans are limited only to the annotations from the API. If I am user of EE I would expect a cooperation between the APIs within the container. I have another view than the API designer. I am the user and I want all API to be interconnected without any blocker in the container but this is not hapenning in reality.

On Mon, Dec 2, 2019 at 5:30 PM Mark Struberg <struberg@xxxxxxxxxx> wrote:

Hi Tibor!

> I have practical experiences with JSR-352.
> The @Transactional, scopes and qualifier do not work in there.

It this is the case, then this is probably a problem with your container. JBatch itself is not to blame here!
Maybe there is also some misunderstanding involved.
One has to understand that the JBatch container does handle transactions differently depending on your batch xml configuration and code.
The use cases are clearly stated in the specification. For a Batchlet you have to control the TX yourself, e.g. via UserTransaction.

But in case of a Chunk based setup (8.2.1, Reader/Processor/Writer) the JBatch container itself does control the transactions via the TransactionManager (or rather TransactionSynchronizationRegistry).
So if you want to control the transactions via @Transactional you will not come far in case of Chunks.
Actually the Interceptor for @Transational should behave completely transparent. It will detect that the TX is already open and simply does nothing. Actually this is exactly the same as if you have nested @Transactional CDI beans.


> Pls rework JSR-236.

I really agree here. There are quite a few weird things with concurrency-utils.

LieGrue,
strub



> Am 02.12.2019 um 13:36 schrieb Tibor Digana <tibordigana@xxxxxxxxxx>:
>
> Hi all,
>
> Pls deprecate JSR-352.
>
> I have practical experiences with JSR-352.
> It is very problematic API.
> The @Transactional, scopes and qualifier do not work in there.
> You would not be able to inject the EntityManager produced by CDI producer.
> If you inject it via @PersistenceContext, the connection would not be closed because here is no scope of batch in terms of Java EE.
> Basically there are outstanding EE beans in this API and therefore it works as another Java SE API and it does not look like.
> Additionally nowadays such jobs are useless without injecting Cloud orchestrator, e.g. Consul, because there you would observe URL pointing to the service executing the Batch Step. Forking such Step would be essential as a new option in a new API.
>
>
>
> Pls rework JSR-236.
>
> It is a new problematic API.
> I reported issues against the Wildfly due to this API is not practicle in commercial EE world.
> You do not have real beans in the executed Task in the ThreadPool.
> If you have a producer of EntityManager, these Task bean won't see it!
> You won't be able to use the scopes because again as in the previous JSR they do not have the end and therefore the JDBC connection is permanently open.
> Pls support using CDI beans in the concurrent Task beans without any additional need to construct them via Proxy.
>
>
> Cheers
> Tibor17
>
>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev