3

My Solution consists of 3 different projects:

  • EJB project with Netbeans auto-generated Facades to manage Entity classes and the persistence.xml

  • Class-Library that holds all @Entity annotated and statically weaved database classes and the remote interfaces for the facade ejb's (shared between EJB and stand-alone client)

  • Stand-alone Client that consists mainly of Swing GUI classes

I use Glassfish 3.1.2, Eclipselink 2.3 as JPA-provider, Netbeans 7.1.1 and a MySQL database. I configured an Ant-task that statically weaves my entity classes on the basis of the persistence.xml.

I have several @OneToOne, @ManyToOne and @ManyToMany annotated relations between the entities decorated with fetch=FetchType.LAZY.

Now I get all along the following errors:

Exception in thread "Mainframe Loader" Local Exception Stack: 
Exception [EclipseLink-7242] (Eclipse Persistence Services - 2.3.2.v20111125-r10461):     org.eclipse.persistence.exceptions.ValidationException
Exception Description: An attempt was made to traverse a relationship using indirection that had a null Session.  This often occurs when an entity with an uninstantiated LAZY relationship is serialized and that lazy relationship is traversed after serialization.  To avoid this issue, instantiate the LAZY relationship prior to serialization.
 at org.eclipse.persistence.exceptions.ValidationException.instantiatingValueholderWithNullSession(ValidationException.java:998)
 at org.eclipse.persistence.internal.indirection.UnitOfWorkValueHolder.instantiate(UnitOfWorkValueHolder.java:220)
 at org.eclipse.persistence.internal.indirection.DatabaseValueHolder.getValue(DatabaseValueHolder.java:88)
 at org.eclipse.persistence.indirection.IndirectList.buildDelegate(IndirectList.java:244)
 at org.eclipse.persistence.indirection.IndirectList.getDelegate(IndirectList.java:414)
 at org.eclipse.persistence.indirection.IndirectList.size(IndirectList.java:752)
 at ch.lawsuite.gui.mail.PosteingangUI.updateDokumentTable(PosteingangUI.java:47)
 at ch.lawsuite.gui.mail.MailboxUI.updateDokumentTables(MailboxUI.java:81)
 at ch.lawsuite.gui.mail.MailboxUI.initMailboxes(MailboxUI.java:37)
 at ch.lawsuite.gui.mail.MailboxUI.<init>(MailboxUI.java:23)
 at ch.lawsuite.gui.MainframeUI.initModules(MainframeUI.java:191)
 at ch.lawsuite.gui.login.LoginUI$MainframeLoader.run(LoginUI.java:131)

Any help is highly appreciated. I completely got deadlocked with this issue for more than a week now :-(

Many thanks in advance!

salocinx
  • 3,715
  • 8
  • 61
  • 110
  • Is this from the "client" that is remotely? If so what did you expect would happen? – esej May 24 '12 at 19:52
  • Yes, the exception is thrown from the remote stand-alone client. I expected that the object which is lazily associated would be automatically fetched from the database when it's being accessed for the first time... Am I wrong with this assumption in this case? – salocinx May 24 '12 at 20:04

1 Answers1

2

Once the entity is passed to a remote client - you can't load none-loaded lazy properties. You need to make sure they are loaded (touch them or something) in the facade that passes them remotely. Static weaving has nothing to do with this. (Well, the automatic process is different with static/dynamic/no weaving - but conceptually for us as developers there is no difference)

esej
  • 3,059
  • 1
  • 18
  • 22
  • Many thanks for your answer. If I understand correctly, the weaving is only for handling entities between the database-layer and the entity-manager? This has to do with the second-level cache? And as soon as the entities are serialized and sent over a network, they are in a un-managed state and has nothing to do with the fetch-type? Sorry, for the many questions, but I think they all can be answered in a single question ;-) – salocinx May 24 '12 at 20:31
  • 1
    There are several ways which an JPA implementation can "handle" entities. Extending (thats why the JPA (2.0 at least) spec requires all entites to have a public or protected default constructor), byte-code-injection-manipulation-of-the-class what (EclipseLink calls this weaving) and some other. For EclipseLink the most efficient (fastest etc) is weaving. I think, but I'm not sure, that there are several things EclipseLink only supports in Weaved mode - for example the second-level cache. ... "are in a un-managed state and has nothing to do with the fetch-type" spot on, exactly right. – esej May 24 '12 at 20:39
  • 1
    I now think to understand the problem. Detached objects are completely out of scope from the JPA provider and thus need comprehensively and manually being managed by the client (in case of 3-tiered solution with a stand-alone client). Many thanks esej! – salocinx May 24 '12 at 21:07