Well, as with all other programming stuff, the better design depends on your
situation.
I agree using and locking the same edting context for request and background
tasks will lock up you app server (multithreaded or not). But maybe you
don't need to lock during the entire background task. If your
On 24.05.2008, at 15:09, Tonny Staunsbrink wrote:
Also bear in mind that accessing the session's editing context
within the performAction thread is a sure path to deadlocks.
Using the sessions editingContext in a background thread with proper
locking/unlocking should be ok I think.
Not real
On 25/05/2008, at 7:09 AM, Tonny Staunsbrink wrote:
On Thu, May 22, 2008 at 3:16 AM, Lachlan Deck <[EMAIL PROTECTED]>
wrote:
On 21/05/2008, at 8:11 PM, Patrick Middleton wrote:
On 21 May 2008, at 10:59, santoshg wrote:
I am using WOLongResponsePage Component in my project.
B
On Thu, May 22, 2008 at 3:16 AM, Lachlan Deck <[EMAIL PROTECTED]>
wrote:
> On 21/05/2008, at 8:11 PM, Patrick Middleton wrote:
>
>>
>> On 21 May 2008, at 10:59, santoshg wrote:
>>
>> I am using WOLongResponsePage Component in my project.
>>> But in the run time, it is showing the
On 21/05/2008, at 8:11 PM, Patrick Middleton wrote:
On 21 May 2008, at 10:59, santoshg wrote:
I am using WOLongResponsePage Component in my project.
But in the run time, it is showing the error message:
Session.context() evaluates to null. You may be trying to
get
On 21 May 2008, at 10:59, santoshg wrote:
Hi All,
I am using WOLongResponsePage Component in my project.
But in the run time, it is showing the error message:
Session.context() evaluates to null. You may be trying to
get the context object
from an arch
