This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Question on find() and getReference()

 
Joe Harry
Ranch Hand
Posts: 10128
3
Eclipse IDE Mac PPC Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Guys,

These two methods can be executed from within or without a transaction? is it true?
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, you are right

The only difference between the "in a transaction" mode and "no transaction mode" is the that if you are in a transaction the retrieved entity is attached to the EM and any possible changes will be persisted if the transaction is ended.

Regards,
M
 
Joe Harry
Ranch Hand
Posts: 10128
3
Eclipse IDE Mac PPC Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Got it. Thanks!
 
Ralph Jaus
Ranch Hand
Posts: 342
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The only difference between the "in a transaction" mode and "no transaction mode" is the that if you are in a transaction the retrieved entity is attached to the EM

This isn't quite correct: If the entity manager has an extended persistence context, the retrieved entity is managed even without a transactional context.
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

I think that in the extended persistence context then you need to commit the changes, manually, but you must do this from a transaction - otherwise you'll get an exception. How do you get this conclusion ? Or I undersand you wrong.

Regards
M
 
Raf Szczypiorski
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But when you call find/ getReference, you don't have to save anything, you read data. Ralph have you the right description.
 
Ralph Jaus
Ranch Hand
Posts: 342
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mihai,

I think that in the extended persistence context then you need to commit the changes, manually

what do you mean by "manually" ? Consider the following scenario:

Given a CMT stateful session bean with extended pesistence context and two business methods m1, m2.
m1 reads data (using find or JPQL queries) and manipulates them with transaction attribute never.
m2 uses transaction attribute Requires_New.

If the client first calls m1 and afterwards m2 the changes from m1 will be commited by the end of m2.
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ralph


Thanks for your answer, but I still don't understand something. If the bean uses the extended persistence context then the comit is not done when the transaction is ended.

why if is the m2 is called before m1 ?

Regards,
M
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,


I'll try to explain.

Even if the bean uses the extended persistence context the m2 overwrite this, that's why the changes are commit after the transaction is ended - and that is after the method ends. After this the method m1 runs.

Am I right ?

Regards
M
 
Ralph Jaus
Ranch Hand
Posts: 342
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mihai,

the only thing I wanted to express was: If you have an extended persistence context, then

1. changes on managed entities aren't lost, even if these changes were not performed within a transaction

2. if the persistence context is synchronized with a transaction at a later point of time, these changes will become persistent when the transaction commits (assume the changes have not been overriden in the meantime and the entities have not become detached in the meantime).

Remarks:

a) Without 2., that means, if the persistence context is never synchronzied with a transaction, none of the changes at the entities will become persistent.

b) In 2: If the entity manager is application managed, the persistence context has to be synchronized with the transaction manually using em.joinTransaction(). If the entity manager is container managed the synchronization is performed automatically by the container.

I'm not sure if this answers your question. If not, please just ask again. It's important for the exam to have a good understanding of persistence contexts.






 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Ralph

Thanks for relieve this aspects. Now everything is clear.

Regards,
M


 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Raf Szczypiorski wrote:But when you call find/ getReference, you don't have to save anything, you read data. Ralph have you the right description.

We might want to save/update after find, surely we cannot update at the time of finding.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic