Re: Is Adding EOAttribute to EOEntity Thread Safe?
Re: Is Adding EOAttribute to EOEntity Thread Safe?
- Subject: Re: Is Adding EOAttribute to EOEntity Thread Safe?
- From: Dov Rosenberg <email@hidden>
- Date: Mon, 31 Mar 2008 18:29:07 -0400
- Thread-topic: Is Adding EOAttribute to EOEntity Thread Safe?
It took us a long time to figure this out. It was indeed caused by improper
locking in our app. We don't use Project Wonder, but we did use the
LockScreamingEditingContext to help us find the problem. That helped a bunch
- another useful gem from Practical WebObjects!!!
Dov Rosenberg
On 3/31/08 5:41 PM, "Chuck Hill" <email@hidden> wrote:
>
> On Mar 31, 2008, at 2:31 PM, Dov Rosenberg wrote:
>
>> That has been our experience - no warning just a sudden shutdown of
>> the app.
>> When deployed out as a servlet the behavior is such that any other app
>> including tomcat still responds but the WO app is effectively dead.
>
> That is a locking defect somewhere in your code. Getting thread dumps
> (jstack is very useful) from the locked app is the only useful way to
> find and fix these.
>
>
> Chuck
>
>>
>> On 3/31/08 5:25 PM, "Chuck Hill" <email@hidden> wrote:
>>
>>> EOF is single threaded at this level. So the threads just wait for
>>> the lock. If you have mis-matched locks (e.g. lock the db context
>>> but
>>> never unlock it), the app just deadlocks. No timeout, no exception.
>>> Just a warm, fuzzy deadlock. try... finally is your friend.
>>>
>>> Chuck
>>>
>>>
>>> On Mar 31, 2008, at 2:21 PM, Dov Rosenberg wrote:
>>>
>>>> Is there a queue where requests get stored in or some sort of
>>>> timeout
>>>> waiting for the lock to release? Or is the failure an outright
>>>> exception?
>>>>
>>>>
>>>> Dov Rosenberg
>>>>
>>>> On 3/31/08 4:25 PM, "Chuck Hill" <email@hidden> wrote:
>>>>
>>>>>
>>>>> On Mar 31, 2008, at 1:15 PM, Dov Rosenberg wrote:
>>>>>
>>>>>> I guess the real problem is trying to run multithreaded apps
>>>>>> against a
>>>>>> single threaded EOF stack. Unless we start using multiple EOF
>>>>>> stacks
>>>>>> we
>>>>>> could potentially have other performance problems lurking in the
>>>>>> shadows
>>>>>
>>>>> More likely from slow fetches and repeated tripping of single
>>>>> faults
>>>>> than this. If you are doing lot of these counts, it would make
>>>>> sense
>>>>> to create a separate EOF stack just for them.
>>>>>
>>>>> Chuck
>>>>>
>>>>>
>>>>>> On 3/31/08 3:39 PM, "Chuck Hill" <email@hidden> wrote:
>>>>>>
>>>>>>> That is how you lock the EOF stack. While the stack is locked,
>>>>>>> no
>>>>>>> other thread can fetch / save. This same lock happens during all
>>>>>>> fetch or save operations.
>>>>>>>
>>>>>>> Chuck
>>>>>>>
>>>>>>>
>>>>>>> On Mar 31, 2008, at 12:09 PM, Dov Rosenberg wrote:
>>>>>>>> Taking a look at the new code I agree it looks a bit safer
>>>>>>>> than
>>>>>>>> the old code. What is the implication for doing an
>>>>>>>> EODatabaseContext
>>>>>>>> lock in a multi threaded app? Will that cause any problems if
>>>>>>>> multiple sessions are trying to do something similar
>>>>>>>> concurrently?
>>>>>>>>
>>>>>>>> Dov Rosenberg
>>>>>>>>
>>>>>>>>
>>>>>>>> On 3/30/08 5:56 PM, "Mike Schrag" <email@hidden>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> It's not thread safe, and Wonder's implementation doesn't
>>>>>>>>> actually
>>>>>>>>> work like this anymore (your code is based on a version from
>>>>>>>>> last
>>>>>>>>> year sometime) ... See
>>>>>>>>> ERXEOControlUtilities._aggregateFunctionWithQualifier for an
>>>>>>>>> example of how to do it properly (we actually create an
>>>>>>>>> attribute
>>>>>>>>> without adding it to the entity)
>>>>>>>>>
>>>>>>>>> ms
>>>>>>>>>
>>>>>>>>> On Mar 30, 2008, at 5:43 PM, Dov Rosenberg wrote:
>>>>>>>>>> We have some code that we are using from Project Wonder (I
>>>>>>>>>> think)
>>>>>>>>>> that adds an attribute programmatically to an EOEntity to do
>>>>>>>>>> things like count, max, etc. (See below). We were doing a load
>>>>>>>>>> test on our application and started throwing errors because a
>>>>>>>>>> different query was submitted using the extra attribute. It
>>>>>>>>>> seems
>>>>>>>>>> that making changes to the EOModel is not thread safe. If that
>>>>>>>>>> is
>>>>>>>>>> the case is there anything we can do to use this code? Or
>>>>>>>>>> should
>>>>>>>>>> we dump this and build a regular fetch for the aggregate data.
>>>>>>>>>> Any
>>>>>>>>>> thooughts or insights would be a huge help.
>>>>>>>>>>
>>>>>>>>>> Query that was generated in error notice the COUNT()
>>>>>>>>>> attribute
>>>>>>>>>> embedded in the query incorrectly
>>>>>>>>>>
>>>>>>>>>> "SELECT t0.ACTUALRATING, t0.BODY, t0.CLOSED, t0.DATEADDED,
>>>>>>>>>> t0.DATEMODIFIED, t0.FORUMID, t0.IPADDRESS, t0.LOCALEID,
>>>>>>>>>> t0.MODERATE, COUNT(t0.RECORDID), t0.PUBLISHED, t0.RECORDID,
>>>>>>>>>> t0.STATUS, t0.TITLE, t0.TYPE, t0.USERID, t0.USERNAME,
>>>>>>>>>> t0.USERNICKNAME, t0.WEIGHTEDRATING FROM DBTOPIC t0 WHERE
>>>>>>>>>> t0.RECORDID = ?" withBindings:
>>>>>>>>>> 1:"0032274bc94901122623a943007f46"(recordID)>:
>>>>>>>>>> Next exception:SQL State:42000 -- error code: 937 -- msg:
>>>>>>>>>> ORA-00937: not a single-group group function
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This is the code that we use to add the temporary attribute.
>>>>>>>>>>
>>>>>>>>>> public static Number
>>>>>>>>>> aggregateNumberFunctionWithQualifier(EOEditingContext ec,
>>>>>>>>>> String
>>>>>>>>>> entityName, String attributeName, String function, EOQualifier
>>>>>>>>>> qualifier) { EOEntity entity =
>>>>>>>>>> EOUtilities.entityNamed(ec,
>>>>>>>>>> entityName); NSArray results = null;
>>>>>>>>>> EOAttribute
>>>>>>>>>> attribute = createAggregateAttribute(ec, function,
>>>>>>>>>> attributeName,
>>>>>>>>>> entityName, "java.lang.Number", "i"); EOQualifier
>>>>>>>>>> schemaBasedQualifier =
>>>>>>>>>> entity.schemaBasedQualifier(qualifier);
>>>>>>>>>> EOFetchSpecification fs = new EOFetchSpecification(entityName,
>>>>>>>>>> schemaBasedQualifier, null); synchronized (entity)
>>>>>>>>>> { entity.addAttribute(attribute);
>>>>>>>>>> try{ fs.setFetchesRawRows(true);
>>>>>>>>>> fs.setRawRowKeyPaths(new
>>>>>>>>>> NSArray(attribute.name())); results =
>>>>>>>>>> ec
>>>>>>>>>> .objectsWithFetchSpecification
>>>>>>>>>> (fs
>>>>>>>>>> ); }finally
>>>>>>>>>> { entity
>>>>>>>>>> .removeAttribute(attribute); } } if
>>>>>>>>>> ((results != null) && (results.count() == 1))
>>>>>>>>>> { NSDictionary row = (NSDictionary)
>>>>>>>>>> results.lastObject(); if
>>>>>>>>>> (row.objectForKey(attribute.name()) != null &&
>>>>>>>>>> row.objectForKey(attribute.name()) instanceof Number)
>>>>>>>>>> { return (Number)
>>>>>>>>>> row.objectForKey(attribute.name()); } }
>>>>>>>>>> return null; }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Dov Rosenberg
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>>>> Webobjects-dev mailing list (Webobjects-
>>>>>>>>>> email@hidden)
>>>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>>>> ns
>>>>>>>>>> io
>>>>>>>>>> n
>>>>>>>>>> .
>>>>>>>>>> com
>>>>>>>>>>
>>>>>>>>>> This email sent to email@hidden
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>>> Webobjects-dev mailing list (email@hidden
>>>>>>>>> )
>>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>>> ui
>>>>>>>>> ra
>>>>>>>>> .c
>>>>>>>>> om
>>>>>>>>>
>>>>>>>>> This email sent to email@hidden
>>>>>>>> _______________________________________________
>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>> Webobjects-dev mailing list (Webobjects-
>>>>>>>> email@hidden)
>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>> ll
>>>>>>>> ag
>>>>>>>> e
>>>>>>>> .
>>>>>>>> net
>>>>>>>>
>>>>>>>> This email sent to email@hidden
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
_______________________________________________
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