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

[Mark Struberg <struberg@xxxxxxxxxx>]

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