Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

hold Entity in session?  RSS feed

 
Luciano A. Pozzo
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello!

How can I hold an entity on Web Application (request/response)?
I just have to put on HttpSession object? Because I don't want to every time load the Entity.... somebody have a good idea to solve, or this is the unique solution?
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Luciano,


How can I hold an entity on Web Application (request/response)?

You basically don't want to do this. There are ways of caching ejbs or other POJOs, but you should probably explain what you�re trying to achieve.
Regards.
 
Luciano A. Pozzo
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Valentin...

Example:
When I have to update an registry, I find the entity them put the data on jsp (ex. customers). So, I change the values and request the update for server with new data. Then I should "find again the entity", this is the problem, I believe that this is not good, every time serch the registry, so I want to know if using session will be better, or if have another solution....

Thank's for help-me
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Luciano,

One thing that I�d like you to be aware about is that from a designer/architect perspective you should always analyze your system from a transaction perspective. You should not be much concerned about reading/writing data from a bean perspective at this level. Hence when you say: first I lookup the bean, second I update the database and third I have to lookup the bean again, etc. This might not be a problem at all, if the first two and the last operation are executing in different transactions. This is how the container was designed to work and this is how enterprise applications should be designed (as a matter of fact the second lookup up is even required, because in the meanwhile the data might be updated by other transactions). However it might be a problem though if all the operations execute in the same transaction and you should probably not lookup the bean twice.
What is the use case you�re trying to implement? Is something like user searching-displaying-updating data? If that�s the case then the second lookup should not bother you at all and it should be executed within another transaction.
 
Luciano A. Pozzo
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Humm.... great Valentim... now I understood!

Now I cant see that is important the "load" method: "the data might be updated by other transactions".

Just more one question: And if my client(browser) request the data from server, the html page is generated. Then another client request the same data, changes and submit, so I cannot control this on web, wright? Because this really bother me, when the data could be inconsistent....

Thank you for the "course"

 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're very welcome Luciano.

Just more one question: And if my client(browser) request the data from server, the html page is generated. Then another client request the same data, changes and submit, so I cannot control this on web, wright? Because this really bother me, when the data could be inconsistent....

You right. The container was designed to keep the data consistency within the duration of a transaction. This means that if two transactions access the same data concurrently, then the data consistency could be guaranteed, providing the appropriate transaction isolation level. However this is not going to work with use cases that span multiple transactions. For example the user-review-book flight ticket use case could easily fail, because the client might spend some time reviewing the sits displayed on the screen, before actually booking a flight (and another client might book the same sit in the mean time). If you want to prevent this from happening, then you should use special design paradigms, like the version number design pattern.
Regards.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!