You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Erik Hatcher <er...@ehatchersolutions.com> on 2004/11/03 10:31:06 UTC

Re: Page recorder is locked after a commit()

On Nov 3, 2004, at 11:08 PM, Matt Raible wrote:
> I'm getting the following error at random when I click on a column 
> heading in my contrib:table.
>
> Page recorder for page users is locked after a commit(), but received 
> a change to property sessionState of component users/table.tableView.
>
> I'm not intentionally saving any sessionState, so it seems quite 
> strange that this is happening.

The @contrib:Table component saves some state automatically (in the way 
that you're using it, its customizable).  It stores the page and column 
sort information.

Are you perhaps hitting the column headings in rapid succession before 
the response has occurred?  This is a classic issue with Tapestry and 
persistent information - Tapestry "locks" the page for the request 
cycle.  If another request comes in for that same session and page 
before the first has finished and "unlocked", you'll see this error.

> <span jwcid="@Block">
> 	<a jwcid="addUserLink@DirectLink" listener="ognl:listeners.add">Link 
> Label</a>
> </span>

Unrelated to the issue, but what's this here for?

> <table jwcid="table@contrib:Table" class="list" id="userList"
>     rowsClass="ognl:beans.evenOdd.next" row="ognl:row" 
> source="ognl:userManager.users"
>     columns="id, firstName, lastName, birthday:new 
> java.text.SimpleDateFormat('MM/dd/yyyy').format(birthday)"
>     arrowUpAsset="ognl:assets.upArrow" 
> arrowDownAsset="ognl:assets.downArrow">

The creation of the SimpleDateFormat here is occurring for every row 
rendered (I believe).  You could make a getter on your page that 
returned an already constructed instance instead.

>     public void detach() {
>         this.message = null;
>         super.detach();
>     }
>
> I'm wondering - could it be the "detach" method?  I used to have 
> persistent="yes" for message, but found that it wasn't needed since I 
> throwing a RedirectException will clear the message.

I don't recall ever having to override detach.  Instead, override 
initialize() - this method, oddly, is called at the *end* of the 
request cycle allowing you to clear state before putting the page 
object back into the pool.  I doubt this is the cause of the issue 
given the error message you got, but should probably be changed anyway.

	Erik


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org