org.hibernate.LazyInitializationException| JBoss.org Content Archive (Read Only)

1. Re: org.hibernate.LazyInitializationException

smarlow Mar 30, 2012 2:30 PM (in response to b69)

Can you show the example code and help answer the following questions.

Is Glassfish lazily fetching the stakeholders? Or are they fetching them before the initial JTA transaction (that loaded the entity) ends?

To get the answers, maybe you could enable some trace logging for EclipseLink, so you know when EclipseLink fetches the initial (one) entity and when it fetches the other (many) entities. Be sure that the application also logs the start/end of the transactional BEAN method as well.

I already know why Hibernate will throw the LazyInitializationException but I'm not sure why Glassfish/EclipseLink doesn't throw it yet. If you can help me better understand why your application doesn't get the error with Glassfish/EclipseLink, I can better answer your question (and help address the problem).

I hope this makes sense.

1 of 1 people found this helpful

2. Re: org.hibernate.LazyInitializationException

b69 Mar 31, 2012 2:09 AM (in response to smarlow)

I didn't trace glassfish until now, but what I can say is, by overriding the default with:

@OneToMany(mappedBy="project", orphanRemoval=true, cascade=CascadeType.ALL,

fetch=FetchType.EAGER)

private List<Stakeholder> stakeholders;

it works with AS 7.1 too!

So, I conclude glassfish ignores the default LACY hint and does an eager fetch. By definition the App-Server implementer is free to interprete the fetching hint.

But the questions remains interesting and I'll try to trace glassfish as you suggest to know what is going on really.

Beside, it's hard to port from glassfish to AS7! The application runs smoth without error on glassfish, but until now I get a crash on AS7 almost on every klick! (ejb concurrent access time out, next to look after, etc.) I'm really just starting!

3. Re: org.hibernate.LazyInitializationException

smarlow Apr 2, 2012 9:36 AM (in response to b69)

Its definitely possible that glassfish is ignoring the default LAZY hint. Other users have complained about that (I would expect not supporting LAZY by default could result in applications that have out of memory problems). The glassfish link here, talks about a workaround for getting lazy fetching to work on glassfish. Please post additional details as to what is going on (when running with glassfish in this situation).

There are two cases that come to mind, where this happens. They both happen with a transaction scoped persistence context (extended persistence will always just work but requires a stateful bean).

Case 1, is when there is no active JTA transaction. The persistence context ends after each entity manager invocation and you never will have a chance to fetch the collection elements (unless as you found, you switch to using EAGER fetching).

Case 2, is when there is an active JTA transaction. The persistence context ends after the JTA transaction completes. You can fetch the collection elements only inside of the active JTA transaction (unless you switch to using EAGER fetching).

b69 wrote:

Beside, it's hard to port from glassfish to AS7! The application runs smoth without error on glassfish, but until now I get a crash on AS7 almost on every klick! (ejb concurrent access time out, next to look after, etc.) I'm really just starting!

Can you try again with the lastest (AS 7.1.1 or nightly build). If the ejb concurrent access timeout still happens, please open a forum post with what you know so far). Reference this post for additional context.

Scott

4. Re: org.hibernate.LazyInitializationException

b69 Apr 3, 2012 9:05 AM (in response to smarlow)

I'm working in a stateful bean, but intentionaly I have not foreseen extended persistence. So case 2 applies, which requires EAGER fetching. I can live with that, because the amount of additional data is small enough to have no impact on loading time. So for the given case rather the default behaviour of glassfish was a surprise, even knowing the fact, that fetching type is no more than a hint.

w.r.t concurrent access time out, I'm already working with AS 7.1.1. Now, at this same moment I'm downloading Build #817. I'm courious about the outcome.

5. Re: org.hibernate.LazyInitializationException

b69 Apr 4, 2012 3:11 AM (in response to smarlow)

I tried with build B#817 and I got the concurrent access time out as before. See trace. Any hint is really appreciated.

Its an AJAX-call from a tab change. before validation happened. I left just the last log entry of it. (Tabs are used to present several text entry fields. On a tab change the content of the text fied is persisted in the database through the mentioned ajax call, see the logging entries:

08:49:45,825 FEIN [ch.commcity.monterosa.web.validate] (http-localhost-127.0.0.1-8080-2) MaxSizeValidator#isValid() outcome TRUE

08:49:45,840 FEIN [ch.commcity.monterosa.web] (http-localhost-127.0.0.1-8080-2) ProjectHandler#handelTabChange entered

08:49:50,880 ERROR [org.jboss.ejb3.invocation] (http-localhost-127.0.0.1-8080-2) JBAS014134: EJB Invocation failed on component ProjectBean for method public abstract ch.commcity.monterosa.entities.Project ch.commcity.monterosa.ejb.Projects.persist(ch.commcity.monterosa.entities.Project) throws ch.commcity.monterosa.ejb.exceptions.BusinessPersistencyException: javax.ejb.ConcurrentAccessTimeoutException: JBAS014360: EJB 3.1 FR 4.3.14.1 concurrent access timeout on org.jboss.invocation.InterceptorContext@3cfcde5a - could not obtain lock within 5000 MILLISECONDS

at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:117) [jboss-as-ejb3-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]