1.@PostConstruct VS init-method
1.1 both BeanPostProcessor
1.2 @PostConstruct is a JSR-250 annotation while init-method is Spring's way of having an initializing method.
1.3 If you have a @PostConstruct method, this will be called first before the initializing methods are called.
1.4 If your bean implements InitializingBean and overrides afterPropertiesSet , first @PostConstruct is called,
then the afterPropertiesSet and then init-method.
2.
EntityManagerFactory emf = ... EntityManagerHolder holder = （EntityManagerHolder）TransactionSynchronizationManager.getResource(emf); EntityManager em = holder.getEntityManager();
3.MethodValidationPostProcessor
A convenient BeanPostProcessor implementation that delegates to a JSR-303 provider for performing
method-level validation on annotated methods.
4.LocalSessionFactoryBean
FactoryBean that creates a Hibernate SessionFactory. This is the usual way to set up a shared Hibernate
SessionFactory in a Spring application context; the SessionFactory can then be passed to Hibernate-based
data access objects via dependency injection.
5.LocalContainerEntityManagerFactoryBean
FactoryBean that creates a JPA EntityManagerFactory according to JPA's standard container bootstrap contract.
This is the most powerful way to set up a shared JPA EntityManagerFactory in a Spring application context;
the EntityManagerFactory can then be passed to JPA-based DAOs via dependency injection. Note that
switching to a JNDI lookup or to a LocalEntityManagerFactoryBean definition is just a matter of configuration!
6.SharedEntityManagerCreator
Delegate for creating a shareable JPA EntityManager reference for a given EntityManagerFactory.
A shared EntityManager will behave just like an EntityManager fetched from an application server's JNDI
environment, as defined by the JPA specification. It will delegate all calls to the current transactional
EntityManager, if any; otherwise it will fall back to a newly created EntityManager per operation.
For a behavioral definition of such a shared transactional EntityManager, see PersistenceContextType.TRANSACTION
and its discussion in the JPA spec document. This is also the default being used for the annotation-based PersistenceContext.type().
14.3.5 Transaction management strategies
Both TransactionTemplate and TransactionInterceptor delegate the actual transaction handling to a PlatformTransactionManager
instance, which can be a HibernateTransactionManager (for a single Hibernate SessionFactory, using a ThreadLocal Session under
the hood) or a JtaTransactionManager (delegating to the JTA subsystem of the container) for Hibernate applications. You can
even use a customPlatformTransactionManager implementation. Switching from native Hibernate transaction management to
JTA, such as when facing distributed transaction requirements for certain deployments of your application, is just a matter
of configuration. Simply replace the Hibernate transaction manager with Spring’s JTA transaction implementation. Both
transaction demarcation and data access code will work without changes, because they just use the generic transaction
management APIs.
For distributed transactions across multiple Hibernate session factories, simply combine JtaTransactionManager as a transaction
strategy with multiple LocalSessionFactoryBean definitions. Each DAO then gets one specific SessionFactory reference passed into
its corresponding bean property. If all underlying JDBC data sources are transactional container ones, a business service can
demarcate transactions across any number of DAOs and any number of session factories without special regard, as long as it
is using JtaTransactionManager as the strategy.
7.
Caused by: org.springframework.beans.factory.BeanCreationException: Could not autowire field: private com.ys.scs.performance.PerformanceService
com.ys.scs.vip.MemberCardService.performanceService; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException:
Error creating bean with name 'performanceService': Bean with name 'performanceService' has been injected into other beans [resetTaskPerformanceService,billAdaptorService]
in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean.
This is often the result of over-eager type matching - consider using 'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.
该问题出现的原因是：在正常加载完依赖后，因为 @Async 注解的出现，又需将该 Bean 代理一次，然后 Spring 发现该 Bean 已经被其他对象注入，
且注入的是没被代理过的版本，于是报错。@Lazy注解可以解决