Fatal编程技术网
  • jpa/
  • JPA Glassfish数据库更新问题

JPA Glassfish数据库更新问题

jpa glassfish

JPA Glassfish数据库更新问题,jpa,persistence,glassfish,java-ee-6,Jpa,Persistence,Glassfish,Java Ee 6,我在Glassfish v3.0.1上部署了一个应用程序，它从数据库中的表中读取事件。一旦准备好，它会将它们标记为已处理。当我试图调用执行更新的方法时，我遇到了一个无法解释的奇怪错误 @Override @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) public void markEventAsProcessed(Long eventId) { try { AtlasEventQueueUpdate

我在Glassfish v3.0.1上部署了一个应用程序，它从数据库中的表中读取事件。一旦准备好，它会将它们标记为已处理。当我试图调用执行更新的方法时，我遇到了一个无法解释的奇怪错误

@Override
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public void markEventAsProcessed(Long eventId) {
    try {
       AtlasEventQueueUpdateAsProcessedQuery setEventAsProcessed = new  AtlasEventQueueUpdateAsProcessedQuery(entityManager, eventId);
       int updateCount = setEventAsProcessed.execute();
       logger.debug("Mark Event [" + eventId + "] processed");
       return updateCount;
    } catch (QueryException ex) {
        logger.error("Event [" + eventId + "has not been marked as processed", ex);
    }
}
在我的应用程序中调用此函数时，我得到以下异常（文章底部的完整跟踪）：

有人知道是什么导致了这个错误吗？我在网上搜索了一下，但没有发现任何有用的东西

2010-08-27 09:44:37,380 ERROR [Ejb-Timer-Thread-1  :EventProvider       ] Unhandled exception in event processing - javax.ejb.EJBAccessException
javax.ejb.EJBAccessException
        at com.sun.ejb.containers.BaseContainer.mapLocal3xException(BaseContainer.java:2262)
        at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2053)
        at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1955)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:198)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:84)
        at $Proxy190.markEventAsProcessed(Unknown Source)
        at com.company.atlas.eventprocessor.provider.EventProvider.processNewEvents(EventProvider.java:170)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1056)
        at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1128)
        at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5292)
        at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:615)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:797)
        at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:567)
        at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:157)
        at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(SystemInterceptorProxy.java:144)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:858)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:797)
        at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:367)
        at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5264)
        at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5252)
        at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:3965)
        at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1667)
        at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:98)
        at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:2485)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.ejb.AccessLocalException: Client not authorized for this invocation.
        at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1850)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:188)
        ... 34 more
我已经删除了目录
domains/domainx/generated/policy/
描述
角色映射信息可用
在特定于Sun的XML中（例如，

sunejbjar.xml
），以及身份验证
可以，但是下面的错误
将显示以下消息：


[...INFO|sun-appserver-pe8.0|javax.enterprise.system.container.ejb|...|
javax.ejb.AccessLocalException: Client not authorized for this invocation.
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:...
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(...)


解决方案
检查EJB模块（
.jar
）
或web模块（
.war
）打包在
一个应用程序（
.ear
），而不
在中包含角色映射信息
应用程序级别，特定于Sun，

sun application.xml
。无论如何
应用程序（
.ear
），安全性
必须保存角色映射信息
在
sun application.xml
中指定。信息技术
两者兼有是可以接受的
模块级XML和应用程序级
XML

我不知道这在你的背景下是否有意义


如果没有，也许可以看看下面的线程。其中一张海报建议将安全日志记录器的日志记录级别设置为FINE[以便]Glassfish策略子系统将记录一条详细消息，描述失败的权限检查的性质。这可能会有帮助。我不能告诉您是否面临同样的问题，但OP通过清理生成的策略文件解决了他的问题：
如果您尝试使用新方法复制和粘贴EJB会话bean，作为修补程序文件来修复bug或合并新功能，也会发生此异常。重新启动服务器或禁用&启用企业应用程序将没有帮助，因为EJB会话bean或实体必须重新打包和重新部署，这样，应用服务器就可以注册新方法，检查并授予/排除EJB会话bean中新的/修改过的方法的访问权限。
将无状态会话bean（TransactionaAttribute.REQUIRES_new）注入其他无状态会话bean时，我也遇到了同样的问题。对我来说，重新启动服务器为我解决了这个问题


只是想让你知道；-）
 我也有同样的问题。我没有在服务上使用任何类型的访问控制，但是在glassfish的一个实例上，一切都很好，在另一个实例上，我得到了这个错误，但只是在一些方法上。我添加了@PermitAll并重新部署了服务，一切都开始工作了
 至少在Glassfish 3.1.2上，有时以前的bean迭代已经发生了更改，会在部署时阻塞Glassfish。应用程序将一直运行，直到它得到任何应该调用但无法调用的代码位为止，因为以前部署的类仍然存在。我认为Glassfish可能会跟踪每一条代码，并防止新代码调用旧代码，但我并没有那么担心，因为解决方案足够简单：


停止服务器，转到域目录并删除应用程序目录中的所有文件和子目录。然后在生成的和osgi缓存目录中执行相同的操作。重新启动服务器并重建/重新部署
 我也有同样的错误，但我的错误是由以下原因造成的：


<c:set var="speciesList" value="#{timberSaleController.distinctSaleSpecies}"   />






职能：


public List<Species> getDistinctSaleSpecies()
    {
        return ejbFacade.getDistinctSpeciesForAllSales();
    }



public List getDistinctSaleSpecies（）
{
返回ejbFacade.getDistinctSpeciesForAllSales（）；
}


当我将set标记更改为此时，它起作用了：


<c:set var="speciesList" value="#{timberSaleController.getDistinctSaleSpecies()}"   />





我删除域文件夹
生成的
，
eclipseApps
，
osgi cache\felix
的内容，以确保重新生成所有必要的文件。请注意，如果描述符中的一个声明中有两个多标记，则会出现此错误-请参阅此操作对我有效。至少对我来说，重新启动glassfish（版本4）和/或重新启动Netbeans也是有效的。Payara团队专注于与此问题相关的问题：@Pascal Thivent:Dude你基本上救了我的命和一家大公司：-）！非常感谢！长命百岁！！

<c:set var="speciesList" value="#{timberSaleController.getDistinctSaleSpecies()}"   />