I presume the alternative of using try-with-resources blocks is not workable? Seems it could be done for EntityManager but problematic to get a transaction.close() in place?

@rbygrave I don't think we would have a good way to detect that an exception had been thrown from code inside AutoCloseable.close(). So no, I don't see a way to do it, though I have not thought deeply about it.

Folks, any feedback on #414?

One issue here is whether we need two flavors of withTransaction(), one void, and the other returning a value.

I think we do, but I don't know what to call them.

@hantsy @Tomas-Kraus @lukasj and everyone else:

1. Are there any votes for renaming to executeInTransaction() + computeInTransaction()?
2. Alternatively, would anyone be in favor of just calling these methods run() and call() or execute() and compute(), and letting you pass in a TxType.REQUIRED, TxType.REQUIRES_NEW, etc.

So according to 2, you would write:

entityManagerFactory.execute(TxType.REQUIRED, entityManager -> {
    entityManager.persist(book);
});

which is obviously quite a lot harder to type than:

entityManagerFactory.executeInTransaction(entityManager -> {
    entityManager.persist(book);
});

But it's not actually that much worse to look at, and it's quite a lot more flexible.

Another argument agains 2 is that the way jakarta.transaction actually defines this enum is IMO pretty nasty:

• for some reason I cannot for the life of me understand, the enum TxType as an inner type of the annotation type @Transactional, making it much less naturally-reusable, and
• TxType doesn't read well at all ... not to mention that it's not a "transaction type", but a transaction propagation type.

We could of course define our own TransactionPropagationType enum, perhaps justifiable on the basis that it's not just for JTA but also for resource-local transactions, but I would really prefer not to go there.

For now, let's go without direct dependency on JTA API which would bring in CDI API (transitively)