This is a matter of what persistence context management you use (Seam or container) and how you scope it. You need to have the upload in a different conversation so the PC is different.

Hello Juan,

maybe you should experiment with
entitymanager.merge( item )

hope it helps.

Can you post more code of your Bean?

entityManager.flush() is what you want since it will update for you. If other entities are changed and you dont want that, you can refresh() those entites. But it sounds like u are doing something wrong if more that the Item
Object is updated.

Hibernate/JPA will always flush all entities in the persistence context, that is just the way they were designed. I think for your use case you are better off using a transaction scoped entityManager. If you are in an ejb3 environment you can inject one using @PersisenceContext, otherwise you are going to need to use the EntityManagerFactory to create one directly.

This means that you will be working with detached entities, so every time you want to update them you will have to merge() them into the entityManager and then call flush().

I have a similar problem. I am wondering did you ever work out a solution to this? My scenario is as follows:

1) Using an extended persistence context I retrieve a bunch of entities.
2) Using a ui:repeat (surrounded by a single form) each entity is displayed along with a submit button.
3) Need somehow to only commit the data that is related to its submit button.

Cheers,

Philip

I've come across this as well, but unfortunately have not seen an elegant way to deal with it. Hopefully, one of the gurus can enlighten us on a better method.

From what I've read, one of the great things about Seam's managed persistence is that you can keep your entities managed throughout a use case, thus not needing to use merge or worry about detached entities, exceptions, etc. that normally plague developers. There are many examples which show using these managed entities directly in the view and flushing the persistence context manually to sync the state to the DB.

This looks great on paper, but in practice, it has its problems as I think we are all seeing. It's all well and good if you have a standard straight forward CRUD I guess. But if you have something more complex (aka real-world, supporting user interaction), it seems to me to break down. If a user can edit several entities in the persistence context throughout a use case but you only want part of them saved at some point, you are sort of out of luck.

My thoughts so far on how to handle this is that you really don't want to be editing the managed entities directly, but rather work on a transient copy with values coming from your managed entity if it is to be edited. Then you want to merge or re-attach the transient copy to the persistence context when you really want it to be synched to the DB. Otherwise you are either forced to synch entities you didn't want synched or forced to lose some of your temporary edits that the user made in the view but wasn't yet ready to synch.

It would be nice if there was an easier way to indicate exactly what you wanted synched (beyond just the automatic dirty checking) or easy way to copy managed entity data to a a transient copy for editing. I'm guessing merge is basically the reverse...copying transient/detached back into a managed entity.

I've also run into some other related problems lately as well. For example, suppose a user visits an interactive edit screen for an entity and makes some changes. Typically I think you would start a long runnning conversation at the beginning of loading the page so that the changes would be maintained througout the use case. Once the save button is clicked, the persistence context with changes can by flushed/synched to the DB and the long-running conversation demoted back to short-running so it will be cleaned up. But in my project there are always links to other pages the user can click at any time, so if the user clicks on one of these links without completing the use case, the long running conversation will go with them (along with the persistence context containing the edited entity). So if the user then went to some other page, perhaps a page allowing editing of some other entity and clicked the save button there, I could see that I may unintentionally be synching out my changes from another page! Maybe I'm wrong on this, but that's how it seems to me. It appears to me that you must take great care to make sure that a new conversation is started when leaving any page where data could be modified or you'll run into these persistence leaks. If I understand correctly, Seam will automatically propogate the conversation unless you take steps to not propogate the conversation...lots of room for error here!

I'm looking forward to hearing if I'm understanding this correctly or not and also if anyone has good ways to deal with this!

Thanks Brandon and Juan. Originally I thought that I could use multiple forms to get the control that I needed. For each element in the repeating data set I would create a separate form - then on submit it would just submit the individual element. However, it appears that multiple forms are not supported within repeating components. Then I thought that I could use Ajax regions. The complete form is submitted, however, it should only process updates for the entity data that lives within the region (assuming button lives within same region). However, part of my application is quite complex where it uses multiple tabs where the first tab acts as a master tab. If data on the master tab is changed it needs to update the other tabs. The only way to do this is to detect the change on the master and then send a request back to the server to update the other entity data that is backing the other tabs. Finally, the other tabs are rerendered and they do indeed now reflect the master tab. This works fine if you have one tab panel, however, I have multiple tab panels, so if the user changes one master tab and then changes another master tab, but only wants to submit the latter, the first one also gets submitted as the data has already been changed back in the entity. What I need is some way to isolate the changes.

Brandon, I need to think a little bit more about your suggestion - I'm too tired at the moment as I've spent the first two days this week trying to track down why I was seeing this (undesirable) behaviour - and the rest of today trying to come up with some solution. I was thinking that the solution lay in using Seam conversations, however, as far as I can tell you cannot create multiple conversations on the same page. Getting a bit worried that is going to be my Waterloo ;-)

I forgot to mention that I also tried to use ajaxKeys to do this but with no success. It is quite tricky to implement this (based on an example implementation by Max Katz - author of Practical RichFaces) as you first need to support indexOf to do the look up to find the current entity. Hibernate generates Sets for entities that refer to other entities, therefore, you need to override hashCode and equals, which we couldn't do as it was a principle in work that we would never add any customizations to the the generated entities. However, this might be possible now since the latest release of seam-gen supports custom code generation (basically you can specify some code for a particular entity and it appends it to the generated entity).

Brandon, you might be on to something with the transient copy, however, this could be a nightmare to keep track of changes, especially, in the case where different entities can be updated via the same page, and this data is repeated many times.

Another point - for validation, generally what is recommended is to use bypassUpdates=true to stop the model been updated. However, I can't use this as I need to update some entities so that they are rerendered correctly on another part of the screen. (however, I don't want these changes commited unless the user explicitly presses the submit button associated with them). The bypassUpdates stops the Application Invocation phase from being invoked so my action method would never be called.

It would be good to hear opinions on good design patterns around this area (or any solution for that matter).

The trick for this type of behavior is to use an event scoped entity manager and merge the entities before updates each time. In a non-ejb environment there are a few steps to follow.

First you need to get hold of an EntityManagerFactory, as you are using the seam managed entity manager factory the process is:

@In EntityManagerFactory entityManagerFactory;

now every time you need an entityManager you need to call

entityManagerFactory.createEntityManager(); 

(remember to call entityManager.close() when you are done with it). As your entity manager will now not last more that one method call you are dealing with detached entities, so they will not be flushed to the database automatically. To update a specific entity you need to do this:

entityManager.merge(myEntity);
entityManager.flush();

This is the correct way to deal with entities that need to be updated piecemeal, however it puts the onus on the programmer to make sure that every entity that needs to be updated is merged into the persistence context. Also you probably need to call entityManager.joinTransaction() after the entityManager is created.

Thanks Stuart. I'll give it a whirl tomorrow and report back soon. Philip