We Keep Coding

JTA for single database

I am just learning JTA and can't understand if I should use it if I have only one database. Currently I use hibernate 5 as JPA provider and if I need to use one transaction between methods I just pass EntityManager as argument.
However, I don't like this method as I need to remember if transaction is opened or not. I would like to find any library that will help me to control transactions (but without Spring) in SE environment. So, should I use JTA in my situation or should I use something different?

Normally when talking about JTA , it refers to the distributed transaction across multiple systems (e.g. across two databases , one database and one JMS compliant message broker). If you only have one database , it is not necessary to use JTA transaction although it should also work. Instead, use a local transaction for one database which should theoretically faster than using JTA transaction.
On the other hands , if you are just talking about #Transactional defined in the JTA , which allow you to declaratively control the transaction boundary by annotating it on a method and without passing the EntityManager between methods , you should look into which frameworks support it.
Under the cover , a proxied EntityManager is injected into different classes such that when it is invoked , it will get the actual EntityManager from the ThreadLocal. So every class in the same thread will get the same EntityManager which prevent you from passing the EntityManager around the methods. A new EntityManager instance will be set to the ThreadLocal just before the #Transactional method is executed using some sort of AOP technique.
Please note that #Transcational is nothing to do with the underlying transaction is JTA or local transaction. It should work for both transaction type.
I would use a framework that support #Transactional such as Spring , Quarkus or Micronaut etc , and configure Hibernate to use local transaction but not JTA transaction for single database.

Shared transaction between multiple applications

we got a requirement of create a transactional operation but handled through multiple applications.
I'm familiar with #Transactional annotation to achieve transactions, or for example using it programmatically like:
#Autowired
private EntityManagerFactory emf;
public void doSomething() {
EntityManager em = emf.createEntityManager();
EntityTransaction tx = em.getTransaction();
tx.begin();
em.createNativeQuery("...do something...").executeUpdate();
tx.commit();
em.close();
}
So, if I need to allow an app to create a transaction dynamically I could pass em as parameter and populate multiple operations from different methods.
However, we got a weird requirement to achieve something like above code but involving multiple applications that share the same database, it would be like a distributed transaction.
Is this feasible with Spring? I'm not sure if I might create some rest services where one of the parameters are the serialized entity managers, although this looks very weird to me. Is it possible to handle like a shared transaction populating operations through multiple apps?

You may involve XA Transactions over JTA. You can use Spring support for JTA which implies use of particular JTA Transaction Manager implementation under the hood such as Atomikos (paid) or Bitronix (Apache-licensed, issues with maintenance now).
Some good overview is also available here, especially describing the alternatives to XA, including description of eventual consistency
Spring Boot + Atomikos sample on Github can demonstrate basics of JTA configuration within single application.
Once you get familiar with all of that, you may have similar question as in this thread. Note, that latter is raised 4 years ago and nothing has changed drastically since that time, so the answers there are still good.
In general, development and implementation of distributed ACID transactions across several applications/services can be a really challenging epic, often comparable by level of effort with re-architecting the whole solution in order to avoid XA usage at all.

When we should use RESOURCE_LOCAL and when use JTA? [duplicate]

I have queries as below:
What is the difference of these two?
Are both of these supported by all databases?
Are JPA TransactionManager and JTA TransactionManager different?

JPA implementations have the choice of managing transactions themselves (RESOURCE_LOCAL), or having them managed by the application server's JTA implementation.
In most cases, RESOURCE_LOCAL is fine. This would use basic JDBC-level transactions. The downside is that the transaction is local to the JPA persistence unit, so if you want a transaction that spans multiple persistence units (or other databases), then RESOURCE_LOCAL may not be good enough.
JTA is also used for managing transactions across systems like JMS and JCA, but that's fairly exotic usage for most of us.
To use JTA, you need support for it in your application server, and also support from the JDBC driver.

As an addition to other answers
Here is an excerpt from the extremely useful article (published on the Apache TomEE website), which can also help answer the OP's first question (the link to the article is below).
Comparing RESOURCE_LOCAL and JTA persistence
contexts
With <persistence-unit
transaction-type="RESOURCE_LOCAL">
YOU are responsible for EntityManager
(PersistenceContext/Cache) creating and tracking...
You must use the
EntityManagerFactory to get an EntityManager
The resulting EntityManager instance
is a PersistenceContext/Cache An
EntityManagerFactory can be injected via the
#PersistenceUnit annotation only (not
#PersistenceContext) You are not allowed to
use #PersistenceContext to refer to a unit of type RESOURCE_LOCAL
You must use the
EntityTransaction API to begin/commit around
every call to your EntityManger Calling
entityManagerFactory.createEntityManager() twice results in
two separate EntityManager instances and therefor
two separate PersistenceContexts/Caches. It
is almost never a good idea to have more than one
instance of an EntityManager in use (don't create a
second one unless you've destroyed the first)
With <persistence-unit
transaction-type="JTA"> the
CONTAINER will do EntityManager
(PersistenceContext/Cache) creating and tracking...
You cannot use the
EntityManagerFactory to get an EntityManager
You can only get an EntityManager supplied by the
container An EntityManager
can be injected via the #PersistenceContext
annotation only (not #PersistenceUnit) You are
not allowed to use #PersistenceUnit to refer to a
unit of type JTA The EntityManager given by
the container is a reference to the
PersistenceContext/Cache associated with a JTA Transaction.
If no JTA transaction is in progress, the EntityManager
cannot be used because there is no
PersistenceContext/Cache. Everyone with an EntityManager
reference to the same unit in the same
transaction will automatically have a reference to the
same PersistenceContext/Cache The
PersistenceContext/Cache is flushed and cleared at
JTA commit time
Anyone interested in learning the Java Persistence API - please do yourself a favor and read the full article here: JPA Concepts: JPA 101.

Resource_Local and JTA are transaction managers (methods of doing transactions). This is not the property of database but the component responsible for coordinating transactions. JPA and JTA transaction managers are different. JPA transaction manager is responsible for JPA transactions and you want to use one if you are only doing JPA transaction. JTA transaction manager is general purpose transaction manager and can enlist other resources such as JMS queues in transaction. Typically Java EE containers employ a JTA transaction manager for EJBs, JPA entities, etc.

resource_local vs JTA its about local transaction vs global transaction. It's about can we manage multiple resources under a single transaction.
CMT vs BMT its about who is opening and closing transaction - application developer or application server.

Application managed JPA, when is Transaction needed

We are working on a little web (will run on Tomcat) with the data layer done with JPA (Eclipselink).
I did similar thing some time ago. But i were always unsure when i need to begin and end transactions or do a flush.
At the moment i use transaction if i add (persist) and remove objects. If i call setters on an already persisted object i do not use transactions.
Is there a guide/ tutorial or a short answer when to use transactions or how to implement application managed JPA correctly.

I think one can summarize an answer to your question.
almost any JPA operation needs a transaction, except find/selects that do not lock entities (i.e any JPA operation that does not change the data).
(JTA transaction-scoped entity manager)
In the case of an JTA transaction-scoped entity manager it is better to quote from the spec (Chapter 3 Entity Operations):
The persist, merge, remove, and refresh methods must be invoked within
a transaction context when an entity manager with a
transaction-scoped persistence context is used.
If there is no transaction context, the javax.persistence.TransactionRequiredException is thrown.
Methods that specify a lock mode other than LockModeType.NONE must be invoked
within a transaction context.
If there is no transaction context, the javax.persistence.TransactionRequiredException is thrown.
The find method (provided it is invoked without a lock or invoked with
LockModeType.NONE) and the getReference method are not required to be
invoked within a transaction context. If an entity manager with
transaction-scoped persistence context is in use, the resulting
entities will be detached; if an entity manager with an extended
persistence context is used, they will be managed. See section 3.3 for
entity manager use outside a transaction.
(Application-managed/resource-local entity manager)
In the case of an Application-managed entity manager, the JPA spec is not clear about the behavior. In the case of Hibernate, it is pretty complicated what happens, when not inside a transaction (it could depend also on the JDBC driver and the autocommit mode of the DB connection). Check Hibernate's article on this theme. Basically you are strongly encouraged to always use transactions for the above mentioned operations.
To the second part of your question: if you called a setter of a managed entity, and without flushing you detached it (i.e before transaction commit), the behavior is unclear/undefined, i.e you should better correct the code.
Example of buggy code:
//begin Transaction
MyEntity entity = em.find(MyEntity.class, 1L);
entity.setField("New value");
em.detach();//it is not sure whether the "New value" will be persisted. To make sure it is persisted, ypu need to call em.flush() before detaching
//commit Transaction
Usually if the order of DB operations (not the same as the order of enity manager operations) is not important, you can leave the JPA implementation to decide when to flush (e.g on transaction commit).

Need to understand transaction.factory_class of Hibernate configuration

In my hibernate.cfg.xml file, one of the properties is -
<property name = "transaction.factory_class"> <!--1-->
org.hibernate.transaction.JDBCTransactionFactory <!--2-->
</property> <!--3-->
Other properties are easy to understand. But, many questions came to my mind when I saw the above property.
line 1 - this specifies the class implementing the Transaction*Factory* interface.
Q1 - I saw the java docs for TransactionFactory but did not understand what it really is. What does this "Factory" mean ? Why don't they call it TransactionGenerator as per the line -
Contract for generating Hibernate Transaction instances.
Q2 - TransactionFactory lead me to Transaction. Is this exactly the same as a Database transaction ?
Q3 -
A single session might span multiple transactions since the notion of
a session (a conversation between the application and the datastore)
is of coarser granularity than the notion of a transaction. However,
it is intended that there be at most one uncommitted Transaction
associated with a particular Session at any time.
...the notion of a session is of coarser granularity than the notion of a transaction.
What does that mean in simple words ?
--
However, it is intended that there be at most one uncommitted
Transaction associated with a particular Session at any time.
Why do you intend this ?
I don't think that the API docs are clear. Makes a n00b life miserable.

Q1 - The reasoning is clear. The transaction creation follows a factory pattern. For example, in an environment where application servers (like JBOSS, WebSphere etc) manage the transaction creation via JTA APIs, you will use a JTA Transaction factory to create transactions and that transactions will be further used by hibernate. In a purely Spring managed environment, Spring can be configured to use a HibernateTransactionFactory. In short, it would follow a similar fashion as:
IFactory f= FactoryCreatorForYourEnvironment.create();
Transaction t = f.create();
Q2 and Q3 - Yes, a hibernate transaction factory creates database transactions on underlying DB. Note that a session may be spanning over multiple transactions - A hibernate session abstracts a database connection. Over the same connection, multiple begin transaction, commit transaction cycles are possible. Example: REQUIRE_NEW properties if the participating beans (EJBs, or SPRING beans). So session is a broader (coarser) term as mentioned in the documentation.
Transactions are required for any writes, deletes, protected reads. So the session holds an implicit transaction. You can read a related stack overflow article here.
HTH.