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 17:31:23 -0400
- Thread-topic: Is Adding EOAttribute to EOEntity Thread Safe?
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.
Thanks
Dov Rosenberg
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:
>>>>>>>> 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:
>>>>>>> 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 (email@hidden)
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>> 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