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 PROTECTED]> 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 PROTECTED]> 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 PROTECTED]> 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 protected])
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimensio
>>>>>> n
>>>>>> .
>>>>>> com
>>>>>>
>>>>>> This email sent to [EMAIL PROTECTED]
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list ([email protected])
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> http://lists.apple.com/mailman/options/webobjects-dev/drosenberg%40inquira
>>>>> .c
>>>>> om
>>>>>
>>>>> This email sent to [EMAIL PROTECTED]
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list ([email protected])
>>>> Help/Unsubscribe/Update your Subscription:
>>>> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-villag
>>>> e
>>>> .
>>>> net
>>>>
>>>> This email sent to [EMAIL PROTECTED]
>>
>>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
