Shulou(Shulou.com)06/01 Report--

This article focuses on "how to understand the abstraction of Spring things". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to understand the abstraction of Spring things.

1.2 understanding the abstraction of Spring framework things

The key to Spring transaction abstraction is the concept of transaction strategy. Transaction policies are defined by TransactionManager, especially the org.springframework.transaction.PlatformTransactionManager interface for imperative transaction management and the org.springframework.transaction.ReactiveTransactionManager interface for responsive transaction management. The following listing shows the definition of PlatformTransactionManager API:

Public interface PlatformTransactionManager extends TransactionManager {TransactionStatus getTransaction (TransactionDefinition definition) throws TransactionException; void commit (TransactionStatus status) throws TransactionException; void rollback (TransactionStatus status) throws TransactionException;}

Although you can use it programmatically from application code, it is primarily a service provider interface (SPI). Because PlatformTransactionManager is an interface, you can easily simulate or stub it as needed. It has nothing to do with lookup strategies such as JNDI. Like any other object (or bean) in the IoC container of the Spring framework, the PlatformTransactionManager implementation is defined. This advantage makes Spring framework transactions worth abstracting, even when using JTA. You can test the transaction code more easily than using JTA directly.

Similarly, in line with the philosophy of Spring, TransactionException unchecked exceptions that can be thrown by any PlatformTransactionManager interface method (that is, it extends the java.lang.RuntimeException class). Failures in the infrastructure of things are almost always fatal. In rare cases, application code can actually recover from transaction failures, and application developers can still choose to capture and process TransactionException. In practice, developers are not forced to do so.

GetTransaction (..) Method returns a TransactionStatus object based on the TransactionDefinition parameter. If there is a matching transaction in the current call stack, the returned TransactionStatus may represent a new transaction or an existing transaction. The meaning of the latter case is that, like the Java EE transaction context, TransactionStatus is associated with the thread of execution.

Starting with Spring Framework 5.2, Spring also provides transaction management abstractions for responsive applications that use responsive types or Kotlin protocols. The following listing shows the transaction strategy defined by org.springframework.transaction.ReactiveTransactionManager:

Public interface ReactiveTransactionManager extends TransactionManager {Mono getReactiveTransaction (TransactionDefinition definition) throws TransactionException; Mono commit (ReactiveTransaction status) throws TransactionException; Mono rollback (ReactiveTransaction status) throws TransactionException;}

The responsive transaction manager is primarily a service provider interface (SPI), although you can use it programmatically from application code. Because ReactiveTransactionManager is an interface, you can easily simulate or stub it as needed.

The TransactionDefinition API specifies:

Propagation: typically, all code within the scope of a transaction runs in that transaction. However, if you run a transaction method when a transaction context already exists, you can specify the behavior. For example, code can continue to run in an existing transaction (as is common), or you can pause an existing transaction and create a new transaction. Spring provides all the transaction propagation options that EJB CMT is familiar with. For information about the semantics of transaction propagation in Spring, see transaction propagation.

Isolation: the degree to which this transaction is isolated from the work of other transactions. For example, can this transaction see uncommitted writes from other transactions?

Timeout: how long the transaction will run before it times out and is automatically rolled back by the underlying transaction infrastructure.

Read-only state: read-only transactions can be used when contemporary code reads but does not modify data. In some cases, such as when using Hibernate, read-only transactions can be a useful optimization.

These settings reflect the standard concept of things. If necessary, refer to resources that discuss transaction isolation levels and other core transaction concepts. Understanding these concepts is critical to using the Spring framework or any transaction management solution.

The TransactionStatus interface provides a simple way for transaction code to control transaction execution and query transaction status. These concepts should be familiar because they are common to all transaction API. The following listing shows the TransactionStatus interface:

Public interface TransactionStatus extends TransactionExecution, SavepointManager, Flushable {@ Override boolean isNewTransaction (); boolean hasSavepoint (); @ Override void setRollbackOnly (); @ Override boolean isRollbackOnly (); void flush (); @ Override boolean isCompleted ();}

Whether you choose declarative or programmatic transaction management in Spring, it is absolutely necessary to define the correct TransactionManager implementation. Typically, you can define this implementation through dependency injection. TransactionManager implementations usually need to understand their working environment: JDBC, JTA, Hibernate, and so on.

TransactionManager implementations usually need to understand their working environment: JDBC, JTA, Hibernate, and so on. The following example shows how to define a local PlatformTransactionManager implementation (in this case, using pure JDBC).

You can define an JDBC data source by creating a bean similar to the following:

The relevant PlatformTransactionManager Bean definition then references the DataSource definition. It should be similar to the following example:

If you use JTA in a Java EE container, you can use the container DataSource obtained through JNDI and the JtaTransactionManager of Spring. The following example shows JTA and JNDI lookups:

JtaTransactionManager does not need to know about the data source (or any other specific resource) because it uses the container's global transaction management infrastructure.

The previous definition of dataSource bean uses tags in the jee namespace. For more information, refer to JEE Schema.

You can also easily use Hibernate local transactions, as shown in the following example. In this case, you need to define a Hibernate LocalSessionFactoryBean that your application code can use to get the Hibernate Session instance.

The DataSource bean definition is similar to the local JDBC example shown previously, so it is not shown in the following example.

If the data source is found through JNDI (used by any non-JTA transaction manager) and managed by the Java EE container, the data source should be non-transactional because the Spring framework (not the Java EE container) manages transactions.

In this case, txManager bean is of type HibernateTransactionManager. Just as DataSourceTransactionManager needs to reference data sources, HibernateTransactionManager needs to reference SessionFactory. The following example declares sessionFactory and txManager bean:

Org/springframework/samples/petclinic/hibernate/petclinic.hbm.xml hibernate.dialect=$ {hibernate.dialect}

If you use Hibernate and Java EE container-managed JTA transactions, you should use the same JtaTransactionManager as the previous JDBC JTA example, as shown in the following example:

If you use JTA, the transaction manager definition should be the same regardless of the data access technology used (whether it's JDBC, Hibernate JPA, or any other supported technology). This is because the JTA transaction is a global transaction and it can enlist any transaction resource.

In all of these cases, there is no need to change the application code. You can change the way transactions are managed simply by changing the configuration, even if the change means moving from a local transaction to a global transaction and vice versa.

At this point, I believe you have a deeper understanding of "how to understand the abstraction of Spring things". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.