5.7. The Mutable interface and @ReadOnly

Many application servers feature HttpSession clustering where changes to the state of mutable objects bound to the session are replicated only when setAttribute is called explicitly. This can lead to bugs that manifest only upon failover, which cannot be effectively tested during development. Further, the replication messages themselves are inefficient, since they contain the entire serialized object graph, bound to the session attribute.

EJB stateful session beans must perform automatic dirty checking (that is, they must automatically detect object state changes to synchronize updated states with the database) and replicate mutable state. A sophisticated EJB container can introduce optimizations such as attribute-level replication. Unfortunately, not all Seam users will be working in an environment that supports EJB3. Therefore, Seam provides an extra layer of cluster-safe state management for session- and conversation-scoped JavaBean and entity bean components.

For session- or conversation-scoped JavaBean components, Seam automatically forces replication by calling setAttribute() once in every request where the component was invoked by the application. However, this strategy is inefficient for read-mostly components. Control this behavior by implementing the org.jboss.seam.core.Mutable interface, or by extending org.jboss.seam.core.AbstractMutable and writing your own dirty-checking logic inside the component. For example,

@Name("account") 
public class Account extends AbstractMutable { 
  private BigDecimal balance; 
  public void setBalance(BigDecimal balance) { 
    setDirty(this.balance, balance); 
    this.balance = balance; 
  } 
  
  public BigDecimal getBalance() { 
    return balance; 
  } 
  ... 
}

@Name("account") 
public class Account extends AbstractMutable { 
  private BigDecimal balance; 
  public void setBalance(BigDecimal balance) { 
    setDirty(this.balance, balance); 
    this.balance = balance; 
  } 
  
  public BigDecimal getBalance() { 
    return balance; 
  } 
  ... 
}

Copy to Clipboard

Toggle word wrap

Or, you can use the @ReadOnly annotation to achieve a similar effect:

@Name("account") 
public class Account { 
  private BigDecimal balance; 
  public void setBalance(BigDecimal balance) { 
    this.balance = balance; 
  } 
  
  @ReadOnly 
  public BigDecimal getBalance() { 
    return balance; 
  } 
  ... 
}

@Name("account") 
public class Account { 
  private BigDecimal balance; 
  public void setBalance(BigDecimal balance) { 
    this.balance = balance; 
  } 
  
  @ReadOnly 
  public BigDecimal getBalance() { 
    return balance; 
  } 
  ... 
}

Copy to Clipboard

Toggle word wrap

For session- or conversation-scoped entity bean components, Seam automatically forces replication by calling setAttribute() once in every request, unless the (conversation-scoped) entity is currently associated with a Seam-managed persistence context, in which case replication is unnecessary. This strategy is not necessarily efficient, so session or conversation scope entity beans should be used with care. You can always write a stateful session bean or JavaBean component to "manage" the entity bean instance. For example:

@Stateful @Name("account") 
public class AccountManager extends AbstractMutable { 
  private Account account; // an entity bean 
  @Unwrap 
  public Account getAccount() { 
    return account; 
  } 
  ... 
}

@Stateful @Name("account") 
public class AccountManager extends AbstractMutable { 
  private Account account; // an entity bean 
  @Unwrap 
  public Account getAccount() { 
    return account; 
  } 
  ... 
}

Copy to Clipboard

Toggle word wrap

Note that the EntityHome class in the Seam Application Framework is an excellent example of managing an entity bean instance using a Seam component.

맨 위로 이동

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

5.7. The Mutable interface and @ReadOnly

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 소개

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links