Re: Concurrent request handling
Re: Concurrent request handling
- Subject: Re: Concurrent request handling
- From: Chuck Hill <email@hidden>
- Date: Tue, 24 May 2011 15:01:16 -0700
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 locked with
> another thread. And now I have a log full of such messages.
> I thought it was me to somehow make a mess to locking. But those log
> messages contain stack traces. And they show that ec was locked by
> MultiECLockManager on Session.awake() as it should have. And that the
> thread is trying to lock ec when doing ec.saveChanges() which action
> could not happen anywhere outside RRloop.
>
> 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?
Can you post the thread traces?
> Interesting thing is that users don't complain about deadlocks in App.
> Also I can see in log that they continue working (in the same session)
> after such issues. So I assume those issues don't cause deadlocks.
> However users do complain that the App is running slow sometimes.
> Maybe that is because of such "local" locks?
My first guess is that your EOEditingContext has a bug in it, and the messages you are seeing are not valid.
Chuck
> 2011/3/10 Chuck Hill <email@hidden>:
>>
>> 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?
>>> I could not find anything interesting on this in documentation.
>>
>> WebObjects has several defaults that are not what most people would want. I think these defaults were set to preserve existing behavior when new features were added. Unless you are sharing unlocked global writable data (from static ivars or Application), there is no reason to NOT have this on. If you are sharing unlocked global writable data, then you are Bad Person and should fix this!
>>
>>
>>> And another question: would concurrent request handling save me from
>>> global application deadlocks when one single request locks on
>>> exception?
>>
>>
>> Maybe. It depends on why that session/request is deadlocking. I would focus on fixing that.
>>
>>
>> Chuck
>>
>> --
>> Chuck Hill Senior Consultant / VP Development
>>
>> Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
>> http://www.global-village.net/products/practical_webobjects
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> С уважением,
> Геннадий Кушнир
--
Chuck Hill Senior Consultant / VP Development
Come to WOWODC this July for unparalleled WO learning opportunities and real peer to peer problem solving! Network, socialize, and enjoy a great cosmopolitan city. See you there! http://www.wocommunity.org/wowodc11/
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden