Hi Paul,

I found the source of my problem. Luckily and it has nothing to do with
Tapestry. Tapestry gets a list of ProductCategory beans from iBatis' cache.
Remember, ProductCategory which contains the troublesome subCategories
field?

My solution was to clone the ProductCategory objest, returned by iBatis,
before making it available to Tapestry.

Cheers,

</Firas>


-----Original Message-----
From: Paul Cantrell [mailto:[EMAIL PROTECTED] 
Sent: den 19 maj 2006 16:57
To: Tapestry users
Subject: Re: Persistence misbehavior in T4

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]

Reply via email to