ActionForms
[2/29]org.apache.struts.action.DynaActionForm
and Mapped Backed Beans [3/29]ActionMappings
[4/29]Action
[5/29]trans-attribute
tag revisited [25/29]ActionForms
[2/29]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.
org.apache.struts.ActionForm
aForm.getValues().getTelephoneText()
validate()
Action
validate
field is true, and validate()
fails, entered data is preserved for redisplay to input
field
reset()
org.apache.struts.action.DynaActionForm
and Mapped Backed Beans [3/29]DynaActionForm
reset()
resets all fields to null
public Object getValue(String key)
and public void setValue(String key, Object value)
ActionMappings
[4/29]Action
object will have a similar behavior for each similar operations, it could be beneficial to reuse the Action
object
ActionMapping
associated w/ a specific path
Action
ActionForwards
ExceptionHandlers
Action
[5/29]
|
|
|
con1
and con2
appear to be ordinary JDBC connections like those we got last week from DriverManager.getConnection()
resource-ref
tag would be set to java:comp/env/OrdersDB
UserTransaction
ejbContext
in EJBs
transaction-type
attribute set to Bean
transaction-type
attribute set to Container
.
container-transaction
section of the assembly descriptor.
|
trans-attribute
Supports
Required
RequiresNew
Mandatory
NotSupported
Never
trans-attribute
determines
Required
UserTransaction.begin()
UserTransaction.commit()
|
trans-attribute
tag revisited [25/29]trans-attribute
tag
Transaction mode | Bean types | Action when called in transaction T | Action when called outside of a transaction |
---|---|---|---|
Required |
Session, Entity, Message-driven | Enlist in T | New transaction |
RequiresNew |
Session, Entity | New transaction | New transaction |
Supports |
Session, Message-driven | Enlist in T | Run without transaction |
Mandatory |
Session, Entity | Enlist in T | Error |
NotSupported |
Session, Message-driven | Run without transaction | Run without transaction |
Never |
Session, Message-driven | Error | Run without transaction |
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
RequiresNew
RequiresNew
is typically used only with objects that have little or no relation to other objects in the system, such as logging objects.
Required
Mandatory
is also a reasonable option, especially for initial development
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.
Dirty Read | Non-Repeatable Read | Phantom Read | |
---|---|---|---|
Read uncommitted | Possible | Possible | Possible |
Read committed | Not possible | Possible | Possible |
Repeatable read | Not possible | Not possible | Possible |
Serializable | Not possible | Not possible | Not possible |
Read Uncommitted
isolation level
Read Committed
Repeatable Read
Serializable