Hi Ben,
thanks, this was very helpful. I now have a better understanding
about this sec stuff and if i find time i will make some tests.
Regards, David
Am 18.11.2005 um 20:11 schrieb Ben Trumbull:
At 11:38 PM +0100 11/17/05, David Teran wrote:
Now my question: if i am not really aware that
At 9:35 PM -0500 11/17/05, Dov Rosenberg wrote:
Can anyone think of a reasonable strategy?
You can eliminate livelock by have the reader threads cooperate with
the updating process.
What I've seen work is that the SEC is updated on a schedule, every X
minutes. The threads check if an updat
At 3:33 PM +1100 11/18/05, Lachlan Deck wrote:
Could you perhaps create a subclass of EOSharedEditingContext,
setting it as the default SEC, and
- implement a readers-writer locking process that will queue readers
if a writer is in the queue so that writer(s) don't get starved.
- i.e., when the
At 11:38 PM +0100 11/17/05, David Teran wrote:
Now my question: if i am not really aware that i am changing such a
shared eo, because a 'set' method in another (non shared) eo changes
something in such a 'shared' eo, then i would normally -not- do this
kind of locking because i simply do not kn
>
>> It seems that calling objectsForFetchSpecification() to either
>> fetch data
>> into the shared editing context or to refresh it too often is a bad
>> thing.
>> When multiple threads are trying to do the same operation - the EOF
>> deadlock
>> occurs.
>
> deadlock or writer starvation? i.e.
Am 18.11.2005 um 04:42 schrieb Karl:The golden rule is not to have any relationships from objects in the SEC to other EOF objects outside of it. Well, this is one golden rule but nothing you can learn from the docs.And: addObjectToBothSides is very slow and this is why i never use it. (its slow if
Hi Dov,
On 18/11/2005, at 1:35 PM, Dov Rosenberg wrote:
For the SEC we do things like:
sec.objectsForFetchSpecification(...)
Which appears to be causing our locking problem under load.
According to what I have learned - objectsForFetchSpecification()
will cause
the SEC to get a write l
Hmm..are we missing the fact that setting Both Side of the
Relationship is a convenience method? ie. if the relationship is
single sided into the SEC then no change occurs?
The golden rule is not to have any relationships from objects in the
SEC to other EOF objects outside of it.
If the
We have been looking deeper into our problems based on all of the
information provided on the newslist. It has been very helpful in
understanding what is happening. Here is the crux of our issue (now that I
understand what is happening)
Our application has 2 parts. One part (the mgmt console) runs
Hi there,
On 18/11/2005, at 9:38 AM, David Teran wrote:
have an additional question: If i am changing an EO which was
fetched into a SEC, i must do something like this according to a
previous mail from you:
regularEC = new EOEditingContext();
regularEC.lock();
try {
regularEC.setShar
So if I do something like
ec.objectsWithFetchSpecification()
And the objects had been previously retrieved by the SharedEC -
would ec be
able to use them?
Yes. This is the pattern I recommend.
The shared objects will be pointer equal, no matter how many
regular ECs are using the
At 10:11 PM -0500 11/16/05, Dov Rosenberg wrote:
We changed the code to do something like this instead:
fetchedRecords = ec.objectsWithFetchSpecification(fetchSpec);
Where ec is our SharedEditingContext. Is that the correct usage?
Yes.
Is it safe to assume that if the SharedEditingCont
At 10:36 PM -0500 11/16/05, Dov Rosenberg wrote:
If I want to use shared objects from a non shared editing context I need to
set the shared ec
SharedEc = EOSharedEditingContext.defaultSharedEditingContext();
EOEditingContext ec = new EOEditingContext ();
ec.setSharedEditingContext(SharedEc);
B
Thanks Art...
On 17/11/2005, at 5:22 PM, Art Isbell wrote:
On Nov 16, 2005, at 5:57 PM, Lachlan Deck wrote:
This might be a surprise (given some of Apple's docs) but the
WebObjects EOModeler User Guide describes these quite well.
http://developer.apple.com/documentation/WebObjects/UsingEOMod
On Nov 16, 2005, at 5:57 PM, Lachlan Deck wrote:
This might be a surprise (given some of Apple's docs) but the
WebObjects EOModeler User Guide describes these quite well.
http://developer.apple.com/documentation/WebObjects/UsingEOModeler/
index.html
The best shared object documentation I ha
On 17/11/2005, at 3:27 PM, Chuck Hill wrote:
I think Ben was pretty clear on this:
The crux of the issue here is that EOSharedEditingContext uses
implementation inheritance from EOEditingContext instead of
composition.
Someone got lazy and inherited from EOEditingContext. Bad OO but
le
Hi again,
On 17/11/2005, at 2:36 PM, Dov Rosenberg wrote:
So if I understand what you are saying here
They work best by using their API to fetch objects you wish to share
into the context, and then creating real EOEditingContexts and having
them use that shared context.
If I want to use sha
I think Ben was pretty clear on this:
The crux of the issue here is that EOSharedEditingContext uses
implementation inheritance from EOEditingContext instead of
composition.
Someone got lazy and inherited from EOEditingContext. Bad OO but
less effort. This is inheritance for behavior no
On 17/11/2005, at 10:45 AM, Ben Trumbull wrote:K.Here's the secret:EOSharedEditingContexts are NOT EOEditingContexts.That's a great secret because the EOSharedEditingContext doc says:Class EOSharedEditingContextjava.lang.Object com.webobjects.eocontrol.EOObjectStore com.webobjects.eocontrol.E
Hi there,
On 17/11/2005, at 2:11 PM, Dov Rosenberg wrote:
We changed the code to do something like this instead:
fetchedRecords = ec.objectsWithFetchSpecification(fetchSpec);
Where ec is our SharedEditingContext. Is that the correct usage?
Well you only want to do this when there's a ne
So if I understand what you are saying here
>
> They work best by using their API to fetch objects you wish to share
> into the context, and then creating real EOEditingContexts and having
> them use that shared context.
If I want to use shared objects from a non shared editing context I need t
Those are some very good pieces of information. We have passed
SharedEditingContexts into methods that expect regular EditingContexts in a
lot of places. Here is an example:
We used to pass a SharedEditingContext into a method so we could use it like
userList = EOUtilities.objectsWithQualifierFor
Hi there,
On 17/11/2005, at 12:41 PM, Ben Trumbull wrote:
At 12:13 PM +1100 11/17/05, Lachlan Deck wrote:
where would you have the sharedEC refetch for newly inserted objects?
As for "when",
That's what I meant...
that depends on when you'd like to make them available to the rest
of the
At 12:13 PM +1100 11/17/05, Lachlan Deck wrote:
where would you have the sharedEC refetch for newly inserted objects?
You can use objectsWithFetchSpecification() on the sharedEC for this purpose.
As for "when", that depends on when you'd like to make them available
to the rest of the applicat
Hi there,
On 17/11/2005, at 10:45 AM, Ben Trumbull wrote:
People successfully use shared ECs in concurrent apps, although
updating shared objects is very difficult to do correctly. I've
seen it done by taking a large granularity lock in the request
handler. However, the following approach
K.
Here's the secret:
EOSharedEditingContexts are NOT EOEditingContexts.
They are only for use as an argument to setSharedEditingContext() and
their own explicit API.
They work best by using their API to fetch objects you wish to share
into the context, and then creating real EOEditingCon
Am 14.11.2005 um 22:02 schrieb Dov Rosenberg: We do have a NSMutableDictionary that we use as an EO cache (primary key is the key).If you want to cache EOs its a good idea to cache their EOGlobalID and get EOs with:gid = eo.ec.globalIdForObject(eo);eo = ec.faultForGlobalId(gid, ec);gid can be seria
Hi there,
On 15/11/2005, at 1:20 PM, Dov Rosenberg wrote:
We took a closer look at our code and made some changes. We were
using a
method out of EOUtilities to get data instead of using
objectsWithFetchSpecification. Hopefully that will clear up our
issue. I
will let everyone know if that
We took a closer look at our code and made some changes. We were using a
method out of EOUtilities to get data instead of using
objectsWithFetchSpecification. Hopefully that will clear up our issue. I
will let everyone know if that works.
A point of clarification:
Based on one of the links that s
Hi there,
On 15/11/2005, at 7:55 AM, Fabian Peters wrote:
as David said, EOSEC requires special care. OTTOMH I'd say the
problem is caused by your use of "objectsWithQualifierFormat".
Agreed. From the EOSharedEditingContext docs:
"Objects can be fetched into a shared context using
objectsW
Title: Re: SharedEditingContext Write Locks?
Hmmm, I kind of suspected that was the case. The whole reason we were using SEC at all was to help performance under load. It doesn’t make sense to have to re-retrieve a lot of the info that is read only for every session that connects up. We tried
On Nov 14, 2005, at 12:06 PM, Dov Rosenberg wrote:
We use shared editing contexts for a portion of our application
that does read only operations. For the most part things work as
expected. Lately we have been experiencing some slow downs that
appear to point to issues within our shared ed
Hi Dov,
as David said, EOSEC requires special care. OTTOMH I'd say the
problem is caused by your use of "objectsWithQualifierFormat". I
normally use
EOSharedEditingContext.defaultSharedEditingContext
().objectsByEntityName().valueForKey("NameOfMyEntity")
You could then qualify on the arr
EOSEC is known to be hard to use. Its very likely that you will have EOF deadlocks, which is what you see below. AFAIK the only way to use it without deadlocks is:load the desired eos at startup and make sure they will -nevernever- change no matter if you fault them into another ec, set sec from th
Title: SharedEditingContext Write Locks?
We use shared editing contexts for a portion of our application that does read only operations. For the most part things work as expected. Lately we have been experiencing some slow downs that appear to point to issues within our shared editing contexts
35 matches
Mail list logo
