@Transactional should support local transaction like Spring

[hantsy]

Like Spring, in a none-EJB and none-JTA, @Transactional should support JPA RESOURCE_LOCAL type persistence context seamlessly in a CDI SE and Servlet/CDI environment.

Besides, add possible to configure transaction support(@Trasnactional) from DataSource for JDBC scenes. Like the Spring DataSource and DataSourceTransactionManager.

I think the Apache DeltaSpike project has done some work like this in the past years. https://deltaspike.apache.org/documentation/data.html#Transactions

Related to jakartaee/persistence#309.

[tomjenkinson]

Thank you for your suggestion!
Unfortunately I am not too clear on what you are suggesting to be added to the Jakarta Transactions project to accomplish the suggestion - please can you elaborate on what the change would look like from the Jakarta Transactions api/specification point of view?

[hantsy]

@tomjenkinson I would like to port the TransactionStrategy of Apache DeltaSpike to Jakarta EE, and make CDI compatible @Transactional annotation(declaration approache) and UserTransaction(or something new class for programmatic approach) works with JTA or local transaction(non-JTA).

For example, in a servlet container, there is a DataSource CDI bean declared, create a local DataSource based transaction strategy, and developers can use @Transactional directly(Currently it does not work in this case).

[tandraschko]

+1, really a important feature when just using CDI + JPA

[tomjenkinson]

Thank you for providing feedback, please can I suggest to create a discussion on the Jakarta Transactions developer mailing list: https://accounts.eclipse.org/mailing-list/jta-dev ?

[hantsy]

Now we are deprecating EJB, @transactional should work on JPA/CDI beans without JTA directly.

[ljnelson]

(Neutral observer.)

My guess is what is being (clumsily and somewhat rashly) proposed is: @Transactional, an annotation clearly squarely defined by the Jakarta EE Transactions Specification, should somehow nevertheless not be defined by the Jakarta EE Transactions Specification (!) in some vague way, and should instead, almost certainly impossibly, have specification-independent semantics that encompass JTA as well as other current and future unspecified "local" applications. Obviously this is the wrong specification locus for such a thing to be proposed, but the general use case is easy to understand. More troublingly from my personal perspective, Jakarta EE currently lacks a place for such a thing to exist.