"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#3984138
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984138
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
