One more question : did this start happening after upgrading to WO5.4.3?
On 15/12/2008, at 1:23 PM, Dov Rosenberg wrote:
According to the docs for EOSharedEditingContext:
In multithreaded applications, shared objects can be used safely by
many
threads at once. Shared editing contexts use NSMultiReaderLocks to
maintain
thread safety. The methods objectsWithFetchSpecification
bindObjectsWithFetchSpecification, faultForGlobalID, and
objectForGlobalID
are thread safe, but the context must be locked before using any other
shared context API.
We use EOUtilities.objectWithPrimaryKey() which uses
objectsWithFetchSpecification() internally.
Dov
On 12/14/08 8:42 PM, "Lachlan Deck" <lachlan.d...@gmail.com> wrote:
Hi Dov,
On 15/12/2008, at 12:11 PM, Dov Rosenberg wrote:
We are using WO 5.4.3. We are also use Project Wonder. Not sure
how to
figure out the Project Wonder version, but it is the latest as of
November.
ok
I am actually suprised that my stacktrace doesn’t have any Project
Wonder
classes in it since we are extending ERXEC and such. Perhaps because
this
editing context is the EOSharedEditing Context.
Correct. EOSharedEditingContext does not extend ERXEC. But that's a
different issue.
Here are the decompiled
lines of WO code that the stack trace is referring to:
com.webobjects.eoaccess.EODatabaseContext.java
public void _fireArrayFault(Object fault) {
EOAccessArrayFaultHandler handler =
(EOAccessArrayFaultHandler)EOFaultHandler.handlerForFault(fault);
if(handler == null) throw new
IllegalStateException("Cannot fire
array fault with a null handler.");
....
MyCode.java
NSArray roles = user.securityRoles(); if (roles != null)
{ for
(int i = 0; i < roles.count(); ++i) { <--- roles.count() starts the
stacktrace. User.securityRoles() returns data under the same user
while not
under concurrent load. The roles array appears to be valid since it
passes
the NULL check
Yeah - the problem is that for some reason (yet unknown) the array
fault is botched.
I'd suggest pinging Pierre on this one.
The questions you skipped though could be helpful:
- memory usage?
- anything special about the entities triggering this? (e.g.,
inheritance) Is it marked as shared in the model?
- are you using locking? Or have you tried using locking? i.e., ERXEC
auto-locking does *not* apply to EOSharedEditingContext.
EOSharedEditingContext
.defaultSharedEditingContext().lockForReading();
try
{
}
finally
{
EOSharedEditingContext
.defaultSharedEditingContext().unlockForReading();
}
On 12/14/08 6:51 PM, "Lachlan Deck" <lachlan.d...@gmail.com> wrote:
On 14/12/2008, at 4:10 AM, Dov Rosenberg wrote:
We don’t throw these errors if we try to debug and step thru the
code – only
under load. These particular EO’s come from the infamous
SharedEditingContext. We use the SharedEditingContext because this
portion
of the app is READONLY and it allows us to share the data between
sessions
instead of having to refetch is for every session.
Memory usage? Any particular entities that trigger this? (e.g.,
any
inheritance).
How are you faulting the data? Locking?
Any thoughts would be appreciated
with regards,
--
Lachlan Deck
with regards,
--
Lachlan Deck
with regards,
--
Lachlan Deck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
