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 <ch...@global-village.net>: >> >> 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/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
