This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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.
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...
Certified Entperise Developer of Websphere
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