On 09/09/2008, at 10:56 AM, Mike Schrag wrote:
More specifically:
/**
* This is Kelly Hawks' fix for the missing to one relationship.
* Delegate on EODatabaseContext that gets called when a to-one
fault cannot find its data in
* the database. The object that is returned is a cl
Yes, but he could link to WOnder or copy that delegate :-)
On 09/09/2008, at 10:56 AM, Chuck Hill wrote:
Yes. But he is not using Wonder. :-)
On Sep 8, 2008, at 5:44 PM, Peter Vandoros wrote:
I think there is a EODatabaseContext Delegate in WOnder (i think
ERXDatabaseContextDelegate) tha
Yes. But he is not using Wonder. :-)
"I think I found your problem right there"
ms
___
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 Subsc
Yes. But he is not using Wonder. :-)
On Sep 8, 2008, at 5:44 PM, Peter Vandoros wrote:
I think there is a EODatabaseContext Delegate in WOnder (i think
ERXDatabaseContextDelegate) that will return null (or throw an
exception, i can't remember) in such cases instead of a dummy fault.
Reg
More specifically:
/**
* This is Kelly Hawks' fix for the missing to one relationship.
* Delegate on EODatabaseContext that gets called when a to-one
fault cannot find its data in
* the database. The object that is returned is a cleared fault.
* We raise here to restore
I think there is a EODatabaseContext Delegate in WOnder (i think
ERXDatabaseContextDelegate) that will return null (or throw an
exception, i can't remember) in such cases instead of a dummy fault.
EOObjectNotAvailableException
ms
___
Do not post ad
I think there is a EODatabaseContext Delegate in WOnder (i think
ERXDatabaseContextDelegate) that will return null (or throw an
exception, i can't remember) in such cases instead of a dummy fault.
Regards
Peter
On 09/09/2008, at 10:32 AM, Chuck Hill wrote:
On Sep 8, 2008, at 5:26 PM, Mik
On Sep 8, 2008, at 5:26 PM, Mike Schrag wrote:
Do you mean that attributes of the EO are suddenly null? I don't
see how this is possible _unless_ you are looking at objects that
are in an EOEditingContext that is not locked. That won't ever
work reliably.
I'm assuming the root problem he
Do you mean that attributes of the EO are suddenly null? I don't
see how this is possible _unless_ you are looking at objects that
are in an EOEditingContext that is not locked. That won't ever work
reliably.
I'm assuming the root problem here is the old JMS stuff would
invalidate objects
Hi Dan,
On Sep 8, 2008, at 4:47 PM, Dan Grec wrote:
On 3-Sep-08, at 4:16 PM, Mike Schrag wrote:
We're having an interesting problem in our apps, and I wanted to
see if anyone else has solved it.
Yes, with an asterisk. As Travis said, use Project Wonder and the
ERXRemoteSynchronizer with
1. We're thinking that the only way to fix this is to start using
Project Wonder and the ERXRemoteSynchronizer for change
notifications. I'm still a little concerned that it won't help our
specific case.
(here is the scary scenario)
We get an NSArray of EO's from a relationship, and are enum
We have started down the rabbit hole as well. Taking a look at Jgroups
(http://www.jgroups.org) it looks like Jgroups can be configured to use JMS
as a transport mechanism. Not sure which version of Jgroups is bundled with
Wonder but it seems like it might be possible without having to write your
o
On 3-Sep-08, at 4:16 PM, Mike Schrag wrote:
We're having an interesting problem in our apps, and I wanted to
see if anyone else has solved it.
Yes, with an asterisk. As Travis said, use Project Wonder and the
ERXRemoteSynchronizer with JGroups support ... The JMS change
notification frame
We're having an interesting problem in our apps, and I wanted to see
if anyone else has solved it.
Yes, with an asterisk. As Travis said, use Project Wonder and the
ERXRemoteSynchronizer with JGroups support ... The JMS change
notification framework is known to have problems under load. I h
On Sep 2, 2008, at 1:55 PM, Sherry Tirko wrote:
We are seeing some similar issues and are also using
session().defaultEditingContext(). Can someone tell me what the
problems are with using the default editing context?
Unless you are doing some sort of change notifications or abusing EOF,
Have you looked at Wonder's ERXObjectStoreCoordinatorPool and
ERJGroupsSynchronizer? I think that's a better approach for the EOF
side.
tb
On Sep 3, 2008, at 9:12 AM, Stephane Guyot wrote:
the question is so interesting
http://www.terracotta.org/web/display/orgsite/What+Is+Terracotta
Hi list,
i'm a little bit in trouble. I post a mail at 10:16:01 and 5 hours
later , nothing on the list ?
I decide to re-send it
Stephane
Tonny,
the question is so interesting
http://www.terracotta.org/web/display/orgsite/What+Is+Terracotta
If anybody has experience with this prod
Tonny,
I totaly agree with you, simple question but the answer is not obvious.
Other people are trying to solve this issue.
http://www.jboss.org/file-access/default/members/jbosscache/freezone/
docs/2.2.0.GA/userguide_en/html_single/index.html#d0e2025
Invalidation :
http://www.jboss.org/fil
Interesting problem, my solution to the problem is: "don't".
Keeping multiple data stores in sync is a pain. It is in WO as is in in any
other distributed environment - for example database clusters. The
challenges are so numerous that i consider sharding a better solution for
load balancing.
In t
Dan,
interesting question and trouble ...
I have no clear answer but question that i hope may help you, see below.
Le 2 sept. 08 à 18:57, Dan Grec a écrit :
Hi everyone,
We're having an interesting problem in our apps, and I wanted to
see if anyone else has solved it.
background:
We're
We are seeing some similar issues and are also using
session().defaultEditingContext(). Can someone tell me what the
problems are with using the default editing context?
Thanks,
Sherry
On Sep 2, 2008, at 12:57 PM, Dan Grec wrote:
Hi everyone,
We're having an interesting problem in our a
Hi everyone,
We're having an interesting problem in our apps, and I wanted to see
if anyone else has solved it.
background:
We're not using page-based editing contexts. Everything (!) is in the
session().defaultEditingContext().
I know, this is bad. We're working hard to fix this for our ne
22 matches
Mail list logo
