SE 452 Lecture Notes

• This is the last required class, next week's class is optional
• Students will be presenting extra credit
  • If you plan on doing an in-person or in-class extra credit assignment you must let me know by tomorrow, Thursday at midnight
    • If you've mentioned it to me casually, or sent me an e-mail to which I responded that's fine if you do xyz, or etc. YOU STILL NEED TO CONFIRM THAT YOU'VE ACCEPTED
    • If you're not sure e-mail me again
  • Notes on both extra-credit options are at the top of lecture notes 6, 7, and 8
  • You need to be able to describe the pattern, it's benefit, how you used it in your sample app, and describe it using UML
  • E-mail me w/ questions
• DL Final
  • Will be after the presentations, next week Mar. 19, CS&T Room 218, starting at 7:30
  • Should only take an hour, you'll have an hour and a half
  • Open book and open note
  • If you need to make other arrangmente you should contact me ASAP
• Two quizzes to hand back
• One quiz to take, but let's finish up Struts first

Today we'll spend a bit of time confirming our understanding of the Struts framework, w/ a bit more detail. Then we'll go onto a more advanced topic of transactions, which will segway some of you nicely into EJBs.

• Extends org.apache.struts.ActionForm
• Transforms input fields into JavaBeans (can also have helper methods)
• Can even nest other beans
  • <html:text property="values.telephoneText" size=14 maxlength=14/>
  • Calls aForm.getValues().getTelephoneText()
• Makes sure browsers don't omit empty fields (e.g.-unchecked checkboxes)
• Serves as firewall, only accepts data specified in bean
• White box
• Maps an HTML Form to submit to Struts Controller, to submit to model
• validate()
  • Servlet will call to validate input before passing to Action
  • If validate field is true, and validate() fails, entered data is preserved for redisplay to input field
  • Why do we need input field? <action-mappings> <action path="/logonSubmit" type="app.LogonAction" name="logonForm" scope="request" validate="true" input="/pages/Logon.jsp"/> </action-mappings>
• reset()
  • Optional
  • Called before form is populated
  • Set initial values
• May implement same interface as backend business object

• DynaActionForm
  • Provided by Struts, configured through XML
  • reset() resets all fields to null <form-bean name="myForm" type="org.apache.struts.action.DynaActionForm" <form-property name="name" type="java.lang.String"/> <form-property name="address" type="java.lang.String"/> </form-bean>
• You can also have a bean backed w/ a map
  • Define public Object getValue(String key) and public void setValue(String key, Object value)
  • Use notation in the jsp like <html:text property="value(key)"/>

• Since servlets are multithreaded and have heavy properties, no need to have more then one, better to have them delegate to lighter weight object
• The Action object will have a similar behavior for each similar operations, it could be beneficial to reuse the Action object
• Decorator Pattern (GoF) for the Action object
• ActionMapping associated w/ a specific path
• Usually configured from xml w/ the following properties
  • path - associated path
  • forward or include or type - If action use type, mapping may just be a forward or include (good for prototyping system until we have an action)
  • className - if you want to subclass Action
  • name - name of associated form bean
  • roles - for standard java security (can ask request object if user has role)
  • scope - request or session for the form bean
  • validate - validate form bean
  • input - where to go if validation fails
  • parameter - general purpose configuration parameter
  • forwards - block of local ActionForwards
  • exceptions - block of local ExceptionHandlers
  • more...

• Access the business layer
• Prepare data objects for the presentation layer
• Exception handling (often)
• Direct to next view
• Thread safe singleton, just like a servlet (mini servlet)
  • request - servlets request context
  • response - response we are creating
  • form - the html action form
  • mapping - action mapping used to invoke this action
• Error handling
  • Can register multiple errors
  • Save errors to the request object before passing the request on
  • List error message by key in ApplicationResources.properties file
  • View with tag
  • Similar protocol for messages being released with Struts 1.1

• 4 key Struts tag libraries
  • bean - access beans and their properties, and define new beans
  • html - creates html forms and elements, interacts with Struts framework, automatic javascript
  • logic - conditional and repeating output, application flow management
  • nesting - tags that provide enhanced nesting capabilities to othe Struts tags
• No longer the only game in town http://java.sun.com/products/jsp/jstl/
• Automatic scoping, if you don't specify a scope to look for it checks for objects by page->request->session->application
• <logic:iterate scope="request" name="result" property="collection" id="row"> <bean:write name="row" property="address"/> </logic:iterate>
• Extended syntax property="foo.bar.baz" -equivalent to-> getFoo().getBar().getBaz()
• Pretty well documented http://jakarta.apache.org/struts/userGuide/resources.html

• Java Transaction Service (JTS)
  • Built on Java Transaction API (JTA)
  • Allows applications to be robust to system and network failures
  • Most of the work transparent to the programmer
    • Handled by the J2EE container
    • Developer - demarcate transaction start and finish
    • Developer - which resources enlisted
    • JTS - everything else
  • JTS's lack of press and transparencty a testiment to its success

• Without transaction management writing reliable distributed applications would be nearly impossible
• We need to modify the persistent state of an application in a controlled manner
• System crashes, network failures, power failures,natural disasters etc. can happen at any time
• Hardware/software failures won't wait for you to be in a valid state

SELECT accountBalance INTO aBalance
    FROM Accounts WHERE accountId=aId;
IF (aBalance >= transferAmount) THEN
    UPDATE Accounts
        SET accountBalance = accountBalance - transferAmount
        WHERE accountId = aId;
    UPDATE Accounts
        SET accountBalance = accountBalance + transferAmount
        WHERE accountId = bId;
    INSERT INTO AccountJournal (accountId, amount)
        VALUES (aId, -transferAmount);
    INSERT INTO AccountJournal (accountId, amount)
        VALUES (bId, transferAmount);
ELSE
    FAIL "Insufficient funds in account";
END IF

• The above code transfers money from one account to another
• Each account balance is represented by a row in a database table
• Why not commit all the changes at once, would that ensure integrity?
  • The rows representing account A and B are likely on different disk blocks, more than one disk IO required for the transfer
  • It is impossible to write multiple data blocks to disk simultaneously
  • Writing every data block to disk when any part of it changes would be bad for system performance
  • Better to defere disk writes to a more opportune time can greatly improve application throughput, even minimize writes! how?
• If the system fails after the first but before the second
  • Money has left A's account, but not shown up in B's
• If the first IO fails but the second succeeds
  • Money will show up in B's account without being debited from A's
• Both accounts are updated, but the account journal is not
  • The activity on the bank statements won't be consistent w/ their accounts
• Concurrency issues, what if A transfers funds to two accounts at the same time
  • Unlucky enough timing and we could have a negative balance

• Transactions provide a framework for enforcing data consistency and integrity in the face of system or component failure
• When resume from the failure we must be able to restore the application's state
  • An application's state encompasses all of the in-memory and on-disk data items that affect the application's operation
  • Everything the application "knows"
• We define our transaction as a related collection of operations on the application state which has the properties of atomicity, consistency, isolation, and durability

• Atomicity
  • All of the transactions' operations are applied to the application state, or none of them are applied
  • The transaction is an indivisible unit of work.
• Consistency
  • The transaction represents a correct transformation of the application state
  • Any integrity constraints implicit in the application are not violated by the transaction
  • The notion of consistency is application-specific
  • In our accounting application, consistency would include that the sum of all debits to accounts equal the sum of all credits
• Isolation
  • The effects of one transaction do not affect other transactions that are executing concurrently
  • From the perspective of a transaction, it appears that transactions execute sequentially rather than in parallel
  • Database systems generally accomplish isolation through a locking mechanism
  • The isolation requirement is sometimes relaxed for certain transactions to yield better application performance
• Durability
  • Once a transaction successfully completes, changes to the application state will survive failures.
  • The system needs to define what is considered survivable
  • A power outage?
  • The building burning down?

• A transaction has three participants
  1. The application
  2. Resource managers (RMs)
     • Store the application's state
     • Usually DB
     • But could be a message queue (JMS in J2EE) or something else
  3. The transaction processing monitor (TPM)
     • Coordinates the activities of the RMs to ensure the all-or-nothing nature of the transaction
     • Almost as old as databases
       • CICS, developed by IBM in the 60's still used today
     • JTS plays this role in the J2EE container
• A transaction begins when the application requests the TPM to start a new transaction
• As the application accesses various RMs, they are enlisted in the transaction
• The RM must associate any changes to the application state with the transaction requesting the changes
• A transaction can end in two ways
  1. The transaction is committed
     • Changes associated with that transaction will be written to persistent storage
     • They become available to other transactions
  2. The transaction is rolled back
     • Happens as a request by the application or because of an RM failure
     • All changes made by that transaction will be discarded

• Transactional RMs summarize the results of multiple transactions in a single transaction log
• Log stored as a sequential disk file (or sometimes in a raw partition)
• Generally written to, only read from during rollbacks
• High performance
  • Only the data that has changed needs to be written
  • Fewer disk seeks, all the changes contained in sequential disk block
  • Multiple concurrent transactions combined into a single write to the transaction log
• In our example: Accounts A and B would be updated in memory, and the new and old balances would be written to the transaction log
• Later the RM will update the actual disks blocks corresponding to the changed data
• If the system fails?
  • upon restart it reapplies the effects of any committed transactions that are present in the log but whose data blocks have not yet been updated.
  • The log guarantees durability across failures
  • Enables us to defer disk IO to a time when they will have a lesser impact on system performance.

• If transaction involves only a single RM
  • Most RMs have their own transaction manager built in
  • RM does most of the work to commit or roll back transaction
  • Handles local transactions (transactions involving only that RM)
• If transaction involves multiple RMs
  • all-or-nothing semantics must apply across all RMs in the transaction
  • TPM orchestrates a two-phase commit
    • TPM first sends a "Prepare" message to each RM
      • Are you ready and able to commit the transaction
    • If it receives an affirmative reply from all RMs?
      • Marks the transaction as committed in its own transaction log
      • Instructs all the RMs to commit the transaction
    • If an RM fails?
      • Upon restart ask the TPM about the status of any transactions that were pending at the time of the failure
      • Either commit them or roll them back.

• Transactions offer simalar features for application data that synchronized blocks do for in-memory data
  • Atomicity
  • Visibility of changes
  • Apparent ordering
• More importantly handles exception-handling
  • In the bad old C days, methods often returned error codes (perhaps like the method below)
  • For each file IO operationyou would have to test the return status
  • If the operation failed, undo all of the previous successful operations and return an appropriate status code
  • Worse if the unit of work is spread over multiple methods or components
  • Transactions delegate all the bookkeeping to the database

public boolean copyFile(String inFile, String outFile) {
  InputStream is = null;
  OutputStream os = null;
  byte[] buffer;
  boolean success = true;

  try {
    is = new FileInputStream(inFile);
    os = new FileOutputStream(outFile);
    buffer = new byte[is.available()];
    is.read(buffer);
    os.write(buffer);
  }
  catch {IOException e) {
    success = false;
  }
  catch (OutOfMemoryError e) {
    success = false;
  }
  finally {
    if (is != null)
      is.close();
    if (os != null)
      os.close();
  }

  return success;
}

• J2EE
  • Much of the work is automatic
  • No need for transaction awarness directly in your component code (or at lease very little...)
• Handled by JTS
  • JTS is a Component Transaction Monitor
  • CTM is an extension of TPM (Transaction Processing Monitor)
  • TPM not OO
    • Manages transactions defined procedurally as sequences of operations on transactional resources
    • Advent of CORBA, DCOM, RMI transactions needed to be defined in terms of invoking methods on transactional objects (i.e. CTM)
    • CORBA created a CTM called Object Transaction Service (OTS)
    • JTS implements OTS interfaces between the Java Transaction API(JTA), a low-level API for defining transaction boundaries, and OTS
    • Allows J2EE to be CORBA compatible
  • More then just a difference in terminology
  • When a transaction in a CTM commits or rolls back, all the changes made by the objects involved in the transaction are either committed or undone as a group.
  • But how does a CTM know what the objects did during that transaction?
  • Which object were involved with what transaction?
  • Transactional components like EJB components don't have commit() or rollback() methods?
  • Nor do they register what they've done with the transaction monitor?

• The application state is manipulated by components
• But stored in transactional resource managers (RDBs, JMSs)
  • Resource managers can be registered in a distributed transaction
• But how does the container figure out what resources are involved in the transaction so it can enlist them?
• Let's look at some sample EJB code, notice we don't call enlist?

  InitialContext ic = new InitialContext();
  UserTransaction ut = ejbContext.getUserTransaction();
  ut.begin();

  DataSource db1 = (DataSource) ic.lookup("java:comp/env/OrdersDB");
  DataSource db2 = (DataSource) ic.lookup("java:comp/env/InventoryDB");
  Connection con1 = db1.getConnection();
  Connection con2 = db2.getConnection();
  // perform updates to OrdersDB using connection con1
  // perform updates to InventoryDB using connection con2
  ut.commit();

• con1 and con2 appear to be ordinary JDBC connections like those we got last week from DriverManager.getConnection()
• But this was actually obtained from doing a JNDI lookup in that specific components deployment descriptor
  • Above your resource-ref tag would be set to java:comp/env/OrdersDB
• Each container provides its own mechanism for creating a DataSource (not specified in J2EE specs)
• The connection pool manager obtains a Connection from the specified JDBC driver, but before returning it to the application, wraps it with a facade (GoF) that also implements Connection, interposing itself between the application and the underlying connection.
• When the connection is created or a JDBC operation is performed, the wrapper asks the transaction manager if the current thread is executing in the context of a transaction, and automatically enlists the Connection in the transaction if one exists.
• JMS message queues
  • Use a similar vendor specific mechanism to wrap your Connections
  • Also published to a JNDI namespace
• JCA (J2EE Connector Architecture)
  • Any other transactional resource (like ERP) must go through this standard

• The above code is bean managed
  • Started and ended explicitly by a component useing UserTransaction
  • Made available through ejbContext in EJBs
  • transaction-type attribute set to Bean
  • Available through JNDI in other J2EE components
• Container managed transactions (or declarative transactions)
  • Started and ended transparently on behalf of the application by the container,
  • Based on transaction attributes in the component's deployment descriptor
  • transaction-type attribute set to Container.
  • Assign transactional attributes at either the EJB class or method levels
  • Specify a default set of transactional attributes for the EJB class
  • Specify attributes for each method if different methods are to have different transactional semantics.
  • Specified in the container-transaction section of the assembly descriptor.

<assembly-descriptor>
  ...
  <container-transaction>
    <method>
      <ejb-name>MyBean</ejb-name>
      <method-name>*</method-name>
    </method>
    <trans-attribute>Required</trans-attribute>
  </container-transaction>
  <container-transaction>
    <method>
      <ejb-name>MyBean</ejb-name>
      <method-name>updateName</method-name>
      </method>
   <trans-attribute>RequiresNew</trans-attribute>
  </container-transaction>
  ...
</assembly-descriptor>

• The options for trans-attribute
  • Supports
  • Required
  • RequiresNew
  • Mandatory
  • NotSupported
  • Never
• trans-attribute determines
  • If the method supports execution within a transaction
  • What action the container should take when the method is called within a transaction
  • What action the container should take if it is called outside of a transaction.
• The most common container-managed transaction attribute is Required
• When Required is set, a transaction in process will enlist your bean in that transaction if that thread is in a transaction
• If that thread is not in a transaction the container will start one for you
• More on this later...

• Transactional Enlistment is always transparent
• Each method call is in the same thread and enlists resources encountered (depending on assembly descriptor)
• This is just mapped by thread id
• BUT IT ALSO IS PROPOGATED IN REMOTE METHOD CALLS!
  • The stubs and skeletons do all the work again transparent to the developer
  • They pass a unique transaction ID over RMI-IIOP if the stub determines the caller is executing a transaction
  • The remote thread accepts that id and acts as part of the transaction

• Container managed beans allow for certain optimizations
• JTS can detect if you components only access one RM, even if different components use many connections
• If there is only one RM we do not need to do a two phase commit

• Demarcation: Marks where our transactions start and stop
• Our decisions on demarcation can have a big effect on application performance, fault tolerence and scalability. Why?
• There are no hard-and-fast rules, but we can make some guidelines that can help our application assembler find a balance between concurrency hazards and performance hazards.

• Container Managed is a lot more flexible
• Bean Managed
  • UserTransaction.begin()
  • UserTransaction.commit()
• Define transactional attributes for each EJB method in the assembly descriptor
  • Specify what the transactional requirements are for each method
  • Let the container determine when to begin and end a transaction

• First rule of transactions: "Keep it short."
  • The 'I' in 'ACID' stands for isolation
    • The effects of one transaction do not affect other transactions that are executing concurrently
  • Resource manager will acquire locks on your behalf on data items you access during the course of a transaction
  • It must hold them until the transaction ends
  • All other transactions that request that lock will be blocked

• Each unique transaction has non-trivial overhead
• We don't want to arbitrarily group many operations in a single transaction
• The above slide told us that this would kill scalability
• We need to focus on the 'C' in 'ACID', consistency
• Can the below code be split up into more than one transaction?

SELECT accountBalance INTO aBalance
    FROM Accounts WHERE accountId=aId;
IF (aBalance >= transferAmount) THEN
    UPDATE Accounts
        SET accountBalance = accountBalance - transferAmount
        WHERE accountId = aId;
    UPDATE Accounts
        SET accountBalance = accountBalance + transferAmount
        WHERE accountId = bId;
    INSERT INTO AccountJournal (accountId, amount)
        VALUES (aId, -transferAmount);
    INSERT INTO AccountJournal (accountId, amount)
        VALUES (bId, transferAmount);
ELSE
    FAIL "Insufficient funds in account";
END IF

• Container-managed transactions allow the container to determine transactional behavior of an EJB method, based on:
  • Our setting of the trans-attribute tag
  • Whether or not our thread is currently in a transaction
• These are the possible behaviors
  • Enlist the method in an existing transaction
  • Create a new transaction and enlist the method in it
  • Do not enlist the method in any transaction
  • Throw an exception

• In container-managed transactions, transaction can only be started if a component calls an EJB method with mode Required or RequiresNew
• When the container creates a transaction as a result of calling a transactional method, that transaction will be closed when the method completes
• If the method returns normally, the container will commit the transaction
  • (unless the application has asked for the transaction to be rolled back)
• If the method exits by throwing an exception, the container will roll back the transaction and propagate the exception
• If a method is called in an existing transaction T and the transaction mode specifies that the method should be run without a transaction or run in a new transaction, transaction T is suspended until the method completes, and then the previous transaction T is resumed

• Session and message-driven beans
  • If you're doing a write you usually want to use Required to ensure that every call will be executed as part of a transaction but will still allow the method to be a component of a larger transaction
  • Reads on static tables, don't enlist in transaction, or performance will tank
  • Exercise care with RequiresNew
    • It should only be used when you are sure that the actions of your method should be committed separately from the actions of the method that called you.
    • RequiresNew is typically used only with objects that have little or no relation to other objects in the system, such as logging objects.
    • How could this leave your code in an inconsistent state
  • For CMP (container-managed persistence) entity beans
    • Usually want to use Required
    • Mandatory is also a reasonable option, especially for initial development
      • This will alert you to cases where your entity bean methods are being called outside of a transaction, which may indicate a deployment error
    • You almost never want to use RequiresNew with CMP entity beans
  • NotSupported and Never
    • Intended for nontransactional resources
    • Such as adapters for foreign nontransactional systems

J2EE architecture encourages decomposition of the application into the smallest convenient processing chunks, and each chunk is processed as an individual request (whether in the form of an HTTP request or as the result of a message being queued to a JMS queue). If you architect this way the Required tag should be less costly.