in black and white
Main menu
Share a book About us Home
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 150 151 152 153 154 155 < 156 > 157 158 159 160 161 162 .. 166 >> Next

004 import javax.ejb.EJBException;
005 import javax.ejb.SessionBean;
006 import javax.ejb.SessionContext;
007 import javax.naming.*;
009 public class GoodTaxCalculatorBean implements SessionBean
010 {
011 public double calculateTax(double cost, String state)
012 {
013 double tax = 0;
015 try
016 {
018 Context ctx = new InitialContext();
019 Context env = (Context)ctx.lookup("java:comp/env”);
020: String taxString = (String)env.lookup("Salestax." + state);
022 if ( taxString != null && !taxString.equals("") )
023 {
Listing 49.3 Using environment entries in our bean
When Transactions Go Awry, or Consistent State in Stateful Session EJBs 433
024 tax = Double.parseDouble(taxString) * cost;
025 }
027 }
028 catch ( NamingException ne )
029 {
030 ne.printStackTrace();
031 // Instead of throwing an EJBException, let's just assume
032 // there is no tax!
033 }
035 return(tax);
036 }
038 public void ejbCreate() {}
039 public void ejbPostCreate() {}
040 public void ejbRemove() {}
041 public void ejbActivate() {}
042 public void ejbPassivate() {}
043 public void setSessionContext(SessionContext sc) {}
045 }
Listing 49.3 (continued)
In this pitfall, we discussed the potential problems our beans may encounter if they use the package to access files and directories on the filesystem. We demonstrated a potentially flawed session bean that loaded a properties file with the class. We listed the programming restriction from the EJB specification and discussed what could go wrong. Finally, we modified our example and provided an alternative to beans loading properties files by using environmental entries in the deployment descriptor. As you are looking through your code base, you may want to look for this potential problem. If you see any code where beans are loading properties files, it will be an easy fix to switch to environment entries.
Item 50: When Transactions Go Awry, or Consistent State in Stateful Session EJBs
Many pitfalls are based on erroneous assumptions—assumptions that, at least on the surface, appear perfectly reasonable. As EJB developers become more educated, one of the first areas they branch out into is transactions. In one way or another, one of their EJBs becomes part of a transaction, and the developer feels confident that his or her code is stable and works correctly because, after all, when a transaction rolls back, the data is rolled back to a consistent state. Herein lies the pitfall; the developer assumed that the state of his or her EJB was rolled back when the transaction failed.
434 Item 50
As you will recall, stateful session EJBs are those EJB components that maintain state between method calls. We can easily imagine such a bean in an example of a police call center. When you call the police operator, he or she remembers the context of your call. In such an example, each question to the call center represents a method invocation on the "call center" EJB. The assumption that EJB developers made was that when the transaction rolled back, the state of all the data within their EJB was restored to its pretransaction state. On the surface, it seems perfectly reasonable.
The problem with stateful session beans and transactions comes from the interaction of bean state and transaction state. The pitfall with session beans comes about as a result of assuming that the bean state is reset to correspond to the pretransaction state when a transaction fails.
Imagine a stateful session bean that represents a bank teller. A client speaks to the bank teller to make a withdrawal. The teller notes that a withdrawal has been requested (transaction start), attempts to perform the withdrawal (method during transaction), and then, depending on whether the teller's cash drawer has enough cash, either commits the transaction (hands cash to the client) or rolls back the transaction ("sorry, I don't have enough cash on hand"). A problem comes about if the client's passbook has already been updated to show the withdrawal. The client's passbook shows the withdrawal, but no cash was given (an inconsistency between the transaction state and the client state).
To solve the problem of inconsistent state within an EJB, we can implement the SessionSynchronization interface on our stateful session EJBs. The Session-Synchronization interface requires you to implement three methods: beforeCom-pletion(), afterCompletion(), and afterBegin(). Figure 50.1 shows the lifecycle of stateful session EJBs. Understanding the lifecycle will clarify exactly how we can use these methods to solve our state problem.
Note that the session synchronization interface is designed to be used with container-managed transactions. Obviously, if you are managing your own transaction state, you would know where transaction boundaries exist and you could store and reset the EJB state yourself.
(6) Transaction start afterBegin()
Previous << 1 .. 150 151 152 153 154 155 < 156 > 157 158 159 160 161 162 .. 166 >> Next