Chuck,
On 28. 2. 2015, at 19:54, Chuck Hill wrote:
>> But. It being the week end and me having at least some time free, I've
>> played with the thing further. I've found that the GIDs are _not_ the
>> culprit actually; the problem happens with localInstancesIn just as well --
>> _presumed I c
Hi,
On 2015-02-27, 3:49 PM, "OC" wrote:
Chuck,
On 27. 2. 2015, at 23:25, Chuck Hill
mailto:ch...@gevityinc.com>> wrote:
You can pass in EOs *if* you don't keep a reference to them (e.g. If you just
localInstance them and then discard the reference before the thread runs as you
are doing). H
Chuck,
On 27. 2. 2015, at 23:25, Chuck Hill wrote:
>>> You can pass in EOs *if* you don’t keep a reference to them (e.g. If you
>>> just localInstance them and then discard the reference before the thread
>>> runs as you are doing). Holding references is problem as then two threads
>>> can
On 2015-02-27, 2:22 PM, "OC" wrote:
Chuck,
On 27. 2. 2015, at 23:04, Chuck Hill
mailto:ch...@gevityinc.com>> wrote:
You can't pass EOs to a background thread. You need to pass EOGlobalIDs to your
runnable constructor instead and then create your new ec on the background
thread when you begi
Chuck,
On 27. 2. 2015, at 23:04, Chuck Hill wrote:
>> You can’t pass EOs to a background thread. You need to pass EOGlobalIDs to
>> your runnable constructor instead and then create your new ec on the
>> background thread when you begin processing. Your constructor is passing
>> full EOs and
Hi,
On 2015-02-26, 11:40 PM, "OC" wrote:
Chuck,
On 27. 2. 2015, at 5:39, Chuck Hill
mailto:ch...@gevityinc.com>> wrote:
You? A weird problem? I am SHOCKED! :-)
:)
I've noticed lately that my background tasks (each of which uses its own EC)
stopped to delete old objects. Pursuing the culp
OC,
FYI - best practices are:
create EC
lock EC
try {
// operations
} catch (Exception e) {
// exception handling
} finally {
unlock EC
}
In your code, if an exception is thrown creating the EC, your finally block
will try to unlock it and generate an NPE.
Ken
> On Fe
Chuck,
On 27. 2. 2015, at 5:44, Chuck Hill wrote:
> I am not. Again I might be missing something, but I understand ERXEC does
> autolock -- even in a background thread -- as needed, albeit possibly not in
> the most efficient manner (e.g.,
> http://lists.apple.com/archives/Webobjects-dev/2007
Chuck,
On 27. 2. 2015, at 5:39, Chuck Hill wrote:
> You? A weird problem? I am SHOCKED! :-)
:)
>> I've noticed lately that my background tasks (each of which uses its own EC)
>> stopped to delete old objects. Pursuing the culprit, I have found that it
>> began when I (by Ramsey's advice)
Hi,
On 2015-02-26, 12:25 AM, "OC" wrote:
On 26. 2. 2015, at 5:14, Ken Anderson
mailto:kenli...@anderhome.com>> wrote:
First, why are you expecting the object to be deleted when you just remove it
from the relationship?
For it is an owning relationship (and it does work all right in the first
On 2015-02-25, 4:07 PM, "OC" wrote:
Hello there,
I've bumped into rather a weird (at least to me) behaviour. Is this normal and
am I just overlooking something by expecting it to work?
You? A weird problem? I am SHOCKED! :-)
I've noticed lately that my background tasks (each of which uses
Ken,
On 26. 2. 2015, at 5:14, Ken Anderson wrote:
> First, why are you expecting the object to be deleted when you just remove it
> from the relationship?
For it is an owning relationship (and it does work all right in the first
case). I might be missing some important point here, but I've al
A couple of things that stand out for me…
First, why are you expecting the object to be deleted when you just remove it
from the relationship?
Second, have you removed calls to lock() and unlock(), or are you not calling
them?
Ken
> On Feb 25, 2015, at 7:07 PM, OC wrote:
>
> Hello there,
>
Hello there,
I've bumped into rather a weird (at least to me) behaviour. Is this normal and
am I just overlooking something by expecting it to work?
I've noticed lately that my background tasks (each of which uses its own EC)
stopped to delete old objects. Pursuing the culprit, I have found tha
14 matches
Mail list logo
