The custom repository implementation should inherit the entity-manager-ref and transaction-manager-ref config [DATAJPA-18]

[spring-projects-issues]

jokeway opened DATAJPA-18 and commented

The Respository customImplementation is very common of using @PersistenceContext and @Transactional to handle custom method. So the customImplementation should inject the 'right' transactionManager (as same as <jpa:repositories /> config).
Use the default spring processing to create the bean is the simplest way, but also lost configurable.So I think we should 'replace' the customImplementation's PersistenceContext and Transactional by the <jpa:repositories /> config, especially when using the AutomaticJpaRepositoryConfigInformation.

---

3 votes, 4 watchers

[spring-projects-issues]

Oliver Drotbohm commented

It's all about annotating your custom implementation with @Transactional("yourTransactionManager") (see Spring reference documentation for details. Same applies to @PersistenceContext

[spring-projects-issues]

jokeway commented

Yes, I know that Spring treatment, so I make the report as type 'Improvement'.
The Respository custom implementation bean registed by 'spring-data', and implemented as part of RepositoryInterface, I think 'spring-data' should handle the Transactional and PersistenceContext automatically by the <jpa:repositories /> setting.

Do not know whether this is a popular demand, but I think that allows me not to modify the code or the base class when switch entity manager factory.

[spring-projects-issues]

wims.tijd commented

annotating custom implementation with @PersistenceContext(unitName="2nd-pu") did not work.
since i have 2 persistenceunits i had to set its dependecy in the config file and call emf.getEntityManger
where i lost the @Transactional config

it think it is not an improvement since the custom methods where querying the wrong database

[spring-projects-issues]

jokeway commented

Has no plan to fix it?

[spring-projects-issues]

Oliver Drotbohm commented

To be honest, no. The main reason I am hesitant to activate this is the fact that this would lead to a gap between what's annotated in the code and what actually is happening. Assume you have a configuration of

<jpa:repositories base-package="…" transaction-manager-ref="myTransactionManager" />

if you now annotate the repository interface as follows:

@Transactional
interface CustomerRepository extends Repository<Customer, Long> { … }

This is highly misleading as - if we follow the suggestion - we would need to trigger a transaction with myTransactionManager which is not in line what @Transactional requires (using the default PlatformTransactionManager if no value attribute is defined). Consider implementing a custom @MyTransactional annotation and equip that with @Transactional("myTransactionManager") to avoid scattering the name al over the repositories.

Beyond that, we have exactly 2 votes for this so far, so I think most users value the alignment with @Transactional semantics

[spring-projects-issues]

Jens Schauder commented

Batch closing resolved issue without a fix version and a resolution indicating that there is nothing to release (Won't fix, Invalid ...)