On May 24, 2011, at 10:50 PM, Кушнир Геннадий wrote:
> Hello
>
>>> How could that be that session is awaken by one thread and action is
>>> invoked by another within the same RRloop?
>>
>> Are you sure that is what is happening? Could it be that you have a bug in
>> your session's sleep() met
Hello
>> How could that be that session is awaken by one thread and action is
>> invoked by another within the same RRloop?
>
> Are you sure that is what is happening? Could it be that you have a bug in
> your session's sleep() method that is sometimes causing the EC to NOT get
> unlocked?
Hi,
On May 24, 2011, at 1:38 AM, Gennady Kushnir wrote:
> Hello again.
> I did turn on concurrent request handling. And now I have some issue
> with ec locking.
> I have subclassed EOEditingContext and this subclass posts alerts to
> the log when a thread attempts to lock ec that was already lock
Hello again.
I did turn on concurrent request handling. And now I have some issue
with ec locking.
I have subclassed EOEditingContext and this subclass posts alerts to
the log when a thread attempts to lock ec that was already locked with
another thread. And now I have a log full of such messages.
Thanks for this. I'm doing a quick code review!
b/w
Mark
On 5 April 2011 18:48, Chuck Hill wrote:
> Hi Mark,
>
> On Apr 4, 2011, at 11:20 PM, Mark Wardle wrote:
>
>> Hi all,
>>
>> There have been a number of threads discussing this runtime option. I
>> think the consensus opinion was that altho
Hi Xavier;
I would probably add accessors to the superclass and then have a helper
singleton to actually cache and factory them into the WOContext, but it
depends on your application design as to what will work best.
Hope this helps.
cheers.
That means I would have as much formatter instan
On Apr 7, 2011, at 8:09 AM, Dev WO wrote:
> Hello Andrew,
>
>>
>> Hi Xavier;
>>
>> I would suggest not putting the formatter in the EO class because the EO is
>> model layer and the formatter really belong as part of the display logic --
>> blurring the two eventually ends up causing design
Hello Andrew,
>
> Hi Xavier;
>
> I would suggest not putting the formatter in the EO class because the EO is
> model layer and the formatter really belong as part of the display logic --
> blurring the two eventually ends up causing design problems in the long-haul.
I completely agree with th
Hi Xavier;
I would suggest not putting the formatter in the EO class because the EO
is model layer and the formatter really belong as part of the display
logic -- blurring the two eventually ends up causing design problems in
the long-haul.
I think in the past when faced with this situation,
Hello Chuck,
Sorry to jump into this to add another question:)
But I would have expected the formatter to not be an issue as it's not actually
writing data.
If you have a stateless app (like full of DA), how would you handle that as you
can actually put the formatter in Session?
Do you have to p
Hi Chuck,
there are 30 different formatters (all NS...) in the application and more than
500 WOComponents. if this is not a potential deadlock case, I'll leave them
there... Too lazy!
I'll try to investigate the deadlocks properly, the problem is that they're
very rare and almost impossible to
Hi Matteo,
I don't think that will cause a deadlock. It will cause some incorrectly
formatted input / output. The easiest fix is to move this from Application to
Session and adjust the bindings.
As for the lockups, you really need to get thread dumps to assess those.
jstack is an easy way t
Hi Chuck,
could you elaborate more on the shared formatters thing?
> Don't Do Stupid Things :-) Which boils down to don't share objects that are
> not thread-safe, or writable data, at the global level unless you have
> appropriate protection. Global being either static members or instance
Hi Mark,
On Apr 4, 2011, at 11:20 PM, Mark Wardle wrote:
> Hi all,
>
> There have been a number of threads discussing this runtime option. I
> think the consensus opinion was that although it is off by default, it
> is better switched on.
I think it is off by default to match the previous (now
>> Hello all !
>> I am wondering whether to turn on concurrent request handling on my
>> deployment or not.
>
> I always have this on.
>
>> What are potential drawbacks of this? I assume there should be some.
>> Why would it be off by default otherwise?
>> I could not find anything interesting on t
On Mar 10, 2011, at 1:22 AM, Gennady Kushnir wrote:
> Hello all !
> I am wondering whether to turn on concurrent request handling on my
> deployment or not.
I always have this on.
> What are potential drawbacks of this? I assume there should be some.
> Why would it be off by default otherwise?
Hello Gennady;
If you are having application-freezes on exceptions that may be another
problem and it may be best to conclusively sort that out rather than
work around it.
cheers.
On 10/03/11 10:22 PM, Gennady Kushnir wrote:
Hello all !
I am wondering whether to turn on concurrent request h
17 matches
Mail list logo
