[jboss-user] [JBoss Seam] - Re: EntityManger-per-user-session...

"iradix" wrote : I think you're biggest problem is you haven't gotten your head wrapped around the conversational model yet. It definitely takes time and I'd recommend that the first thing you do is at least skim through the Seam reference documentation in it's entirety. I've read the documentation in it's entirety at least 20-30 times now. "iradix" wrote : That being said, I'll try to explain as best I can. | | anonymous wrote : I don't understand this part at all. I know that if I stick the edited activity back into the users collection of activites and have the correct cascade type, that when I save the updated user, it will save the updated activity as well. | | Where you're going wrong here is you don't need to stick the activity back into the list if it's already there. Hibernate documentation says specifically that I'm responsable for managing both sides of a bi-directional relationship. I've never experienced the behavior you're talking about, and even though I'm injecting my EntityManager through the @PersistenceContext, I'm pretty sure it's still conversationally scoped becuase I specififed it in the following way... | @PersistenceContext(type=PersistenceContextType.EXTENDED, unitName="testDatabase") | EntityManager em; | "iradix" wrote : If you are using a conversationally scoped EM (which is what my suggestions are based on) then there will only be one version of each activity per conversation, whether that activity was retrieved through user.getActivities or through SELECT..... That's how an EntityManager works and it's important to understand that. This is true only if that conversationally scoped EM has the User bean as an attached instance. Otherwise, it will most definitely not recognize that the detached entity comming from the users activities collection is the same as the attached entity being injected from the conversation scope. "iradix" wrote : So rather than the view that you provided, what I'm talking about is the edit view where you will have values bound like: | | | | Name: <h:inputText value="#{selectedActivity.name}"/> | | | | When the update data model phase happens the name would be updated on the one and only version of the selected Activity, which is managed by your conversation scoped EM, and when the transaction is commited it will be updated. After that anytime you access user.getActivities() you will see the updated activity and it will be reflected in the database. Does that make more sense? That does not happen in my code, and my EM is conversation scoped because it is an extended persistence context managed by a conversationally scoped SFSB. (do you still call them session beans if they're not session scoped... lol) "iradix" wrote : anonymous wrote : I guess that's what I'm saying. I'm not sure I'd call it spanning more than one conversation. In reality, user is a session scoped bean representing the currently logged in user. | | Well, since a session may contain many conversations, then your User object at least has the capability of spanning more than one and that should be factored in. Again, this seems to be an issue with your understanding of how conversations, and more specifically conversation scoped EMs work. You cannot use the @PersistenceContext annotation to specify a conversation scoped EM. Okay, I need to read more carefully. You're saying that even though the owner of this EM is conversationally scoped, and the PersistenceContextType is extended, that it's not a conversationally scoped EM? I thought the whole point of setting it to extended was that Seam garuntee's me that the same EM will be available across multiple method calls to the same object (in this case, ActivityActions). In fact, both the DVDStore and the Booking app don't use an EM set up through components.xml and injected using the @In annotation. "iradix" wrote : It needs to be injected using the @In annotation, and if you've configured that correctly (see the docs on how) Seam will magically make sure that the same EM gets injected into every bean within the same conversation. Okay, I'm completly re-working my demo app to use what you've specified. Somehow, I have a feeling we're still not communicating the whole picture to eachother, but I'm willing to learn. :) "iradix" wrote : As far as persistence units are concerned, I've never had the need to deal with more than one on a project, but I'd imagine if I did I could create 2 Seam managed EMs, one for each persistence context and then your example would become: | | | | | @In(create="true") | | EntityManager manager1; | | | | @In(create="true") | | EntityManager manager2; | | | | Where manager1 and manager2 are both properly configured, conversation scoped EMs. I didn't at first realize you were talking about configuring EM's through the use of components.xml. In that case, it's perfectly trivial to inject multiple EntityManagers tied to different persistence contexts. "iradix" wrote : | Make more sense? | No, but I'm working on some demo code to see if I can begin to understand. Also, even though I'm grateful for your help, this has also seemed to stray a long way from what I was originally asking, which is... why is it so bad to just have a Session scoped EM. However, I'd be much more interested in getting it to work the "correct way" than to find out why the wrong way is wrong. /sigh P.s. You say that I never have to merge, but in reality, em.find(User.class, userId) is doing the same thing (not the same operation, but I mean what it's doing is querying the database and reattaching my detached user). The whole point of my question is, why do I have to always worry about my session scoped objects becomming detached because the scope of my persistence context < scope of my seam component. I don't care if it's em.find() or em.merge(), both seem kind of silly to have to do each time. It seems to me that it should be entity managers job to keep track of this for me, rather than me having to worry in every business method on every action to ensure that all of my objects are attached to the current entity manager. Especially when you think of a user with a large collection of activities. Then you can imagine that just editing one activity requires a database trip that could bring back 3-4k records or more. I mean, that's not going to be the case here, of course, but I'm just wondering why it needs to be this way. Don't get me wrong, I'm reading what you've posted and I'm even reworking my example to see if I can make some sense of what you're saying. I'm always trying to learn more. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984138#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...