Is the Bean shared across pages? If it is a Tapestry @Bean, I really
don't think you need to synchronize on it, either. You may, however,
need to clear it out between requests.
Maybe others can clarify: does Tapestry pool bean instances?
P
On May 19, 2006, at 2:48 AM, Firas A. wrote:
Paul: "You should generally not need to synchronize access to instance
fields of a page."
Firas: The synchronized methods are in the JavaBean class
containing the
subCategories field, not in a page class. Which answers your question.
A little clarification:
CategoryBrowser is a page class (typeof BasePage).
CategoryBrowser uses an instance field, ProductCategory (a javabean)
ProductCategory uses an instance field, subCategories of type List
All operations on subCategories (in ProductCategory!) are synchronized
It's the subCategories that's been kept in memory.
Regards,
</Firas>
-----Original Message-----
From: Paul Cantrell [mailto:[EMAIL PROTECTED]
Sent: den 18 maj 2006 19:39
To: Tapestry users
Subject: Re: Persistence misbehavior in T4
A few general points:
-- An "= null" initializer for a non-final field is redundant in
all cases.
-- You should generally not need to synchronize access to instance
fields of
a page.
Now a question:
In the CategoryBrowser.pageDetached() the ProductCategory property is
set to null.
Don't you mean subCategories is set to null? If it's not, then
that's your
problem. Page objects get reused.
Cheers,
Paul
On May 18, 2006, at 12:26 PM, Firas A. wrote:
Hello Everyone!
I have a class, CategoryBrowser of type BasePage which has a
transient
property, a JavaBean called ProductCategory. ProductCategory makes
use
of an instance field:
private List<Category> subCategories = null;
This list is initialized in CategoryBrowser upon every request.
Every access
to subCategories is synchronized. In the
CategoryBrowser.pageDetached() the
ProductCategory property is set to null.
The problem:
The state of the subCategories field is retained between requests.
During
all subsequent requests after the 1st one, the initial value of
subCategories is not null (dispite the declaration above).
And when this happens the current state of subCategories may even be
observed in another browser/session. Here's the test that I
performed:
1. initiate the misbehavior in Firefox
2. close Firefox and start Opera
3. browse to the page where subCategories is first initialized
The result: the state of subCategories reflects the state it got in
Firefox (1), i.e. it is was not null upon first request and already
contained some values from the session in Firefox.
Any idea on what's going on?
My platform:
Tapestry 4.0.1 (started with -Dorg.apache.tapestry.disable-
caching=true)
JVM 1.5.0_06-b05 / WinXP SP2
Tomcat 5.5.9
Latest Firefox, Opera and MSIE
Thank you for your time!
</Firas>
_________________________________________________________________
Piano music podcast: http://inthehands.com Other interesting stuff:
http://innig.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
