-
1. Re: LongLived mechanism
kkoster Apr 21, 2005 8:19 AM (in response to rlhatcher)From what I understand and have done with the implementation, when the detached Client object is returned to the context of the bean, you will need to merge it back into the EntityManager's context. In your case
@FlushMode(FlushModeType.NEVER) public void updateClient(Client theClient) { this.theClient = theClient; this.theManager.merge(this.theClient) }
Or, alternatively if you don't want the state of theClient to be persisted only after calling saveClient, defer the merge until then. The FlushMode annotation can be removed. -
2. Re: LongLived mechanism
rlhatcher Apr 21, 2005 8:37 AM (in response to rlhatcher)That does make sense to me, however I don't see the benefit of having a LongLived manager since the process of using the entity and merging it back in doesn't really take advantage of the long livedness (if that's a word). Or is it simply a convienent place to store the entity in between steps? I'm beginning to feel as though I'm using a feature simply because it exists, not that it solves a particular problem I have.
-
3. Re: LongLived mechanism
bill.burke Apr 21, 2005 8:39 AM (in response to rlhatcher)kkoster is correct. You must merge().
BTW, there is no reason to create a DTO. Entities can become DTOs. The Value object pattern is dead. -
4. Re: LongLived mechanism
bill.burke Apr 21, 2005 8:50 AM (in response to rlhatcher)It is less useful since you are merging...But it is still useful because no SQL UPDATE, INSESRT, or DELETE will happen until you flush() (or the container does it for you). So, merge()ing will not update the database if the flush mode is NEVER. (neither will persist() or remove()). Am I making sense?
-
5. Re: LongLived mechanism
rlhatcher Apr 21, 2005 9:00 AM (in response to rlhatcher)That makes perfect sense. It matches conceptually whith what I had in mind, but I was overcomplicating the implementation slightly. Thanks for the help, you've saved me a lot of time.
-
6. Re: LongLived mechanism
ffray Apr 22, 2005 6:10 AM (in response to rlhatcher)Hi guys!
Did I miss something? No TOs? How do you transfer
the data to the client? By sending the whole Entity?
Isn't it a bit uncool to serialize a whole entity if it is
a top level one correlating with dozends of other entities
and those to the whole rest of the underlying db-structure?
Even if most things aren't loaded it might be a nice
packet to send, isn't it!?
How do you restrict the data to the needed portions?"bill.burke@jboss.com" wrote:
kkoster is correct. You must merge().
BTW, there is no reason to create a DTO. Entities can become DTOs. The Value object pattern is dead. -
7. Re: LongLived mechanism
bill.burke Apr 22, 2005 1:42 PM (in response to rlhatcher)@OneToMany(fetch=FetchType.LAZY)