Affects Version/s: 1.9.1 (Evans SR1)
we had some bad time trying to figure why some of our operations did not reach the database. in the test project we have to repositories, one is called "FailingPersonRepository" and one "SucceedingPersonRepository".
also, there is a test case that runs the same logic on both repositories and as the name suggest one of the repository fails the test.
we have a custom repository factory bean as well as the repository factory that in this repro case does nothing more that wrapping the repisotry in an impl (that does more in the actual project than here).
there are also two base interfaces for our repository, the first one (CrudRepository) contains some mehtods related to the earlier mentioned impl (methods truncated for this testcase) and the second one (LongCurdRepository) extends the first and eliminates the generic ID part of the first Repository.
this is needed as we are directly accessing the repositories throu GWT requestfactory and in our case they try to find e.g. a delete(java.lang.Long) but without the overriden methods in the LongCrudRepository there is only delete(java.io.Serializable) at runtime.
here starts the issue. when not overriding the `delete` method the call to delete succeeds. but as soon as we have the delete(Long) in our repository we get a "InvalidDataAccessApiUsageException: No transactional EntityManager available" exception.
our debugging shows that at this pont the `specificMethod` is the one from the LongCrudRepository (and for our CrudRepository it is the delete from SimpleJpaRepository) and therefore there is no transaction.
while there is a workaround (putting @Transactional on the delete in LongCrudRepository) we wanted to confirm if this behaviour is wanted or if there is a chance to see a change in a future release.