JBossDeveloper

That looks like a good solution to what I was trying to explain...avoiding direct updates on managed entities. I'll have to play around with this on my own project! Thanks for the tip!

As far as validation and related problems, I'll confess I tried several approaches and never found anything that solved all my problems, so I hobbled together my own validation system that allows me the precise control I wanted. My problem was validation occuring on fields that hadn't been updated yet and then the failures causing other processing (due to user interactions) to be aborted. Also, validation messages were disappearing when I still wanted them shown due to the nature of FacesMessages and also not working properly for me in data tables. There may be better ways of dealing with these problems, but for now I just wanted to continue moving forward and didn't have the time to spend figuring it out, so I rolled my own.

I've been looking into what Stuart has said i.e. using detached entities. If I take this route, which it looks like I'm going to have to take, I am going to lose most of the benefits of Seam as I'm going to have to revert to managing the persistence of entities with JPA/Hibernate. I am now experiencing the dreaded Lazy Initialization Exception (LIE).

Let's recap my example:

1) Find a bunch of entities.

2) Each entity is displayed back to the user in a separate tab panel with a save button (actually, not only are the details of the entity displayed in the tab, but also details of some of its associated entities as well).

3) The user may change an entity which can change other entities associated with it. (He may or may not decide to save this entity).

4) The user should be able to choose which entities he wants to save.

The problem of course is that once an entity is changed it cannot be excluded from the flush/commit.

To overcome the LIE, one solution that I am contemplating is as follows:

1) User starts to edit an entity. Fire event back to the server to evict it and add it to a map keyed on it's PK in the backing bean (shouldn't run into LIE as all data has been retrieved for the entity being edited). If entity is already in map it'll just be overwritten.
2) If user eventually decides to save this entity, I can send the PK of entity back to backing bean and merge/reattach it and remove from map.

For the fine grained control that I require, it also appears that JPA would do the job easily as there is no evict command for a single entity. Looks like I'm going to have to set up Hibernate to work with Seam.

Brandon - regards the validation issues - I guess you've already tried to use bypassUpdates.

Aside on getting the EntityManagerFactory (emf)

Three things hook the emf back to your code.

1) Your data source (project-dev-ds.xml) jndi-nme
2) Your persistence unit (persistence.xml) jta-data-source should be 
same name as jndi name in 1.
3) Your components setup (components.xml) persistence:managed-persistence-context
persistence-unit-jndi-name should match your persistence unit name in step 2.

Right, so far so good. One thing I don't understand is why 
jboss.entity.manager.factory.jndi.name is used for the EntityManager when there 
is also a parameter called jboss.entity.manager.jndi.name

I would have thought that you could set something up like this in your
 persistence-dev.xml file.

<property name="jboss.entity.manager.jndi.name" value="java:/myEntityManager"/>
<property name="jboss.entity.manager.factory.jndi.name" value="java:/myEntityManagerFactory"/>
     
}

Minor typo - For the fine grained control that I require, it also appears that JPA would NOT do the job easily as there is no evict command for a single entity. Looks like I'm going to have to set up Hibernate to work with Seam.

To get around the lazy initilisation exceptions another approach that you could try is to configure a seam managed pc but with event scope rather than conversation scope. This should get around the LIE's on the first request, but you will still have to merge the entities to update them.

Thanks Stuart. Not too sure how reducing the scope further could stop the LIE's.

1) Backing bean entity is at event scope (or any scope for that matter)
2) User searches for some entities and displays them in same page below search area. Before request returns the entity manager is closed i.e. persistence context is gone.
3) User is bunched when trying to display results - as EL that refers to entities from pc that search used is closed, a LIE is raised when one of the entities associations is traversed.

Could you elaborate slightly on your suggestion - I'm obviously missing your point.

With a seam managed event scoped em it will still be active while the page is rendered, if you are using a em directly obtained from a em factory it will not be.

If you want to do pagination/expanding grouped results or whatever you will still have to merge.

I've tried to use the Event Scope, which does get rid of the LIE, however, now when I try to refer to one of the entities (e.g. user selects a dropdown and I need to fire an event back to the server to process the current entity), the entity is null that is passed back to the server, I guess because it is out of scope at this stage. Any ideas?

Are you using s:entityConverter? If so try using a custom converter.

I mean't s:convertEntity. Beer and programming don't mix.

Hi Stuart,

Glad you're enjoying yourself - not too sure if beer and computers are conducive to each other ;-)

This is a snippet of the code where the market entity is null by the time it arrives back on the server.

<a4j:support event="onchange"
action="#{myAction.updateEwMaster(market)}"
ajaxSingle="true"/>

So, I'm not using any converter here.

Juan, not too sure why you are seeing null here - I'm pretty sure that I'm seeing null as the entity is now out of scope. That's an interesting find about JBoss EL. As I am using Seam I would already be using JBoss EL - object passing etc.

I agree that working at the event level would be quite tricky after the page is rendered back to the user as everything in the backing bean from this point onwards is out of scope.

I am going to try and set up Hibernate with Seam. Then I'm going to try going back to using Session scope with the evict entity and save to map pattern that I've alluded to in an earlier post.

I was thinking about this event scoped entityManager thing again today, and I'm curious if this would work...basically reversing the usage of conversation and event scoped entityManagers as discussed above.

You could use the normal Seam-managed conversation scoped entityManager for all your interactive editing as before...this is good because it maintains the state the user expects across interactions. Then once the Save action is triggered for a specific entity, you could create an event scoped entityManager and merge the edited entity into that entityManager and flush the changes. Only the changes you wanted would be synched to the DB and the editing would remain independent and avoid LIEs, detached entities, etc. Seems like this would work pretty well unless I've overlooked something. Any thoughts?