[hibernate-issues] [Hibernate-JIRA] Updated: (HSEARCH-88) Workspace.getIndexReader AssertionFailure: Tries to read for update a index while a writer is accessed
Charles Chappell (JIRA)
noreply at atlassian.com
Thu Jun 21 20:22:52 EDT 2007
[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Charles Chappell updated HSEARCH-88:
------------------------------------
Attachment: Login.java
I'll hopefully have a test case sometime today. I added this issue before I went to sleep last night, and am working on simplifying the issue today. The problem is at present that this involves:
App Client ->
Web Service ->
EJB ->
Hibernate Persistence/Search
Basically I have a "login" function that checks to see if a user "admin" and other "initial" data exists. If no, it creates the data, and returns the newly created "admin" user to the calling web service, which then uses this in a further processing step to create a login session, and a stateful web service endpoint with an associated stateful EJB. (nice and simple huh?)
In the process of doing this, 6 different entity beans are touched, including the offending "Login" bean.
------ Update ------
The NPE was actually being caused by the exception, and it's not *easily* reproducible in the login step. That seems to be a race condition between the updates from the initial insert, and grabbing data when the login process is proceeding. Frankly, I'm not sure how though, as I use the entity beans that I created during the initial data creation step in the following login steps. In any event, I was only able to produce that once, and the assertion failures I'm getting now are in different, but related functions.
In all cases, it's centering around a single association of my main class though, so I'm posting the classes here for perusal.
I am working on a test case for this, so this is informational at this point, but know that this class is always the one reported. It's entirely possible that I've misconfigured something in this class, but this is also the only class I use that has a @ContainedIn notation. I'll post the Person class that this links to as well. I keep getting assertion failures for EntityManager.find operations under GlassFish Build 41, using the previously noted versions of Hibernate.
Here's a trace of the exception that I was able to get. (I did try to get it from within the EJB, but it doesn't show up, even if I do a try { entire function mentioned } catch (Throwable t) { t.printStackTrace(); }
org.hibernate.annotations.common.AssertionFailure: Tries to read for update a index while a writer is accessedclass org.mc3.entity.party.Login
at org.hibernate.search.backend.Workspace.getIndexReader(Workspace.java:54)
at org.hibernate.search.backend.impl.lucene.LuceneWorker.remove(LuceneWorker.java:85)
at org.hibernate.search.backend.impl.lucene.LuceneWorker.performWork(LuceneWorker.java:73)
at org.hibernate.search.backend.impl.lucene.LuceneWorker.performWork(LuceneWorker.java:41)
at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueProcessor.run(LuceneBackendQueueProcessor.java:37)
at org.hibernate.search.backend.impl.BatchedQueueingProcessor.performWorks(BatchedQueueingProcessor.java:131)
at org.hibernate.search.backend.impl.PostTransactionWorkQueueSynchronization.afterCompletion(PostTransactionWorkQueueSynchronization.java:50)
at com.sun.enterprise.distributedtx.J2EETransaction.commit(J2EETransaction.java:491)
at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:371)
at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3781)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3560)
at com.sun.ejb.containers.StatefulSessionContainer.postInvokeTx(StatefulSessionContainer.java:1373)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1343)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1305)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:205)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:83)
at $Proxy175.find(Unknown Source)
at org.mc3.ccms.web.service.Session.find(Session.java:119)
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:585)
at com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:232)
at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:132)
at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:241)
at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:74)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:559)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:518)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:503)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:400)
at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:70)
at com.sun.enterprise.webservice.MonitoringPipe.process(MonitoringPipe.java:147)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:79)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:559)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:518)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:503)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:400)
at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:70)
at com.sun.enterprise.webservice.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:218)
at com.sun.enterprise.webservice.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:129)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:79)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:559)
The EJB Find function mentioned here is extremely simple:
@PersistenceContext
private EntityManager em;
public Object find(Class klass, Object object) {
return em.find(klass,object);
}
> Workspace.getIndexReader AssertionFailure: Tries to read for update a index while a writer is accessed
> ------------------------------------------------------------------------------------------------------
>
> Key: HSEARCH-88
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-88
> Project: Hibernate Search
> Issue Type: Bug
> Affects Versions: 3.0.0.beta3
> Environment: Hibernate 3.2.4.sp1, PostGRESQL
> Reporter: Charles Chappell
> Priority: Minor
> Attachments: Login.java
>
>
> May be an application server interaction.
> Somewhat sporatic, but always in the same places in my code. Basically I had one class that created an entity exit via NullPointerException, (Database updates were successful) and a second attempt to read the same data was made, and failed due to this assertion. The only connection to Hibernate Search is via the Annotations/Runtime, nowhere in this process did I directly use Hibernate Search.
> I'll attempt to produce test code, since this is the simplest case that I've gotten this assertion failure in.
> Application Server is Glassfish, reproducable both on OSX and Solaris 10 Intel.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the hibernate-issues
mailing list