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