关于Spring JPA存储库事务性的1个快速问题.我有一个未标记为事务性的服务,并调用Spring JPA存储库方法
userRegistrationRepository.deleteByEmail(email);
它被定义为
@Repository
public interface UserRegistrationRepository extends JpaRepository<UserRegistration, Long> {
UserRegistration findByEmail(String email);
void deleteByEmail(String email);
}
问题是它失败了" 没有实体事务可用于当前线程的EntityManager - 无法可靠地处理'删除'调用;嵌套异常是javax.persistence.TransactionRequiredException "异常.
好吧,我可以通过将服务或 deleteByEmail(..)方法标记为事务来解决它,但我无法理解为什么它现在崩溃.Spring文档明确声明" 默认情况下,存储库实例上的CRUD方法是事务性的. "(http://docs.spring.io/spring-data/jpa/docs/current/reference/html/#transactions),但显然这个不是......那么这个陈述只与成员有关CrudRepository吗？
ps:那是Spring Data JPA 1.9.4
语境
我们有一个批处理作业，可将本地化的国家/地区名称（即国家/地区名称翻译成不同语言）从外部数据库复制到我们的数据库。这个想法是在一个块中处理一个国家的所有本地化国家名称（即第一个块 - 安道尔的所有翻译，下一个块 - 阿联酋的所有翻译，等等）。我们JdbcCursorItemReader用于读取外部数据+一些oracle分析函数来提供该国可用的翻译总数：类似
select country_code, language_code, localized_name, COUNT(1) OVER(PARTITION BY c_lng.country_code) as lng_count
from EXT_COUNTRY_LNG c_lng
order by c_lng.countty_code, c_lng.language_code
问题
因此，按块切割此输入看起来很简单：当您读取了 中指定的确切行数时停止块lng_count并使用下一个读取行开始一个新的行，但实际上似乎并不那么简单:(
首先要尝试的是自定义完成策略。但问题是，它无权访问最后一个项目，读取者ItemReader- 您应该明确地将其置于阅读器的上下文中，并将其恢复到策略中。不喜欢它，因为它需要额外的阅读器修改/添加阅读器侦听器。此外，我不喜欢来回序列化/反序列化同一个项目。而且我不觉得JobContext/StepContext是存放此类数据的好地方。
还有RepeatContext，它看起来像这样的数据一个更好的地方，但我没能得到它容易...
所以最后我们得到了这样的解决方案：
@Bean(name = "localizedCountryNamesStep")
@JobScope
public Step insertCountryStep(
final StepBuilderFactory stepBuilderFactory,
final MasterdataCountryNameReader countryNameReader,
final MasterdataCountryNameProcessor countryNameProcessor,
final MasterdataCountryNameWriter writer) {
/* Use the same fixed-commit policy, but update it's chunk size dynamically */
final SimpleCompletionPolicy policy …在我们的应用程序中观察到一个非常奇怪的情况(具有所有默认BOM依赖性的Spring Boot 1.5.6):您可以完美地登录(with AbstractPreAuthenticatedProcessingFilter),但这仍然留Principal在请求中null!即request.getUserPrincipal()是null,而SecurityContextHolder.getContext().getAuthentication()不是!
这反过来会影响我们的健康端点敏感的能力:它使用Principal(参见HealthMvcEndpoint.exposeHealthDetails(HttpServletRequest,Principal)),它被注入ServletRequestMethodArgumentResolver,然后从请求中获取它...
看起来我错过了一些简单的东西,但仍然无法找到它:(