• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Question to Kyle Brown

 
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi kyle,
My question might be a wrong one but I am just asking to make a clarification. I request apologies if the question is an absurd one.
I was going trhu one of the chapters of "Enterprise Java Programming with IBM WebSphere " which discuss about
"The session facade and data bean solution"
In this solution a servlet requests a session bean which inturn gets the data of an entity bean into a data bean(an oridnary java bean) and returns the data bean to the servlet. The idea is to reduce the network calls to the EJB and to have a local representation of data. But if the underlying data in DB gets updated or modified, the data bean becomes stale. If u r getting the info from the entity bean then there is a fair chance of getting the most recent data as it gets updated by activate/passivate actions. How far am I correct and how to address this problem ?
Regards,
Mustang.
 
Ranch Hand
Posts: 217
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Your concern is valid, that's why you may want to adopt Optimistic locking to validate your data in memory is consistent with the one in DB.
Generally, each invocation to Entity Bean will invovle ejbLoad() first. And in WAS, you can use Pessimistic locking for this operation, which in turn will use select ... for update to locking the underlying record, so later on your biz operation in this transaction has the right data in hand.
But usually, the lock should not expand user's thinking time. So you won't lock the record and wait till user operates. You can use version attribute in your object to stamp it with some version, and if other people change the record in DB, the version will mismatch and transaction will not go through.
Both transaction styles are supported from WAS 4.0.2, so...
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Simon's posting is correct. The idea is that the Data access bean (or Value object) does not survive user think time. It only lasts as long as it takes to build and display the web page. Thus it is possible that the data could become stale in the short amount of time (milliseconds) between obtaining the data from the session bean and building the web page in the JSP.
If your EJB values change faster than the time it takes to build a web page, you're in bigger trouble than we can help you with
Kyle
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic