Thanks Mike for clarifying things. Now it makes sense to me why and where we
need to lock / unlock EC.
Nobody wants to deal with nasty problems but if they are there, one must know
the root cause.
Farrukh
On 2010-05-01, at 11:30 PM, Mike Schrag wrote:
> You don't have to lock immediately upo
You don't have to lock immediately upon making an EC, rather you have to lock
around anything that touches the EC. That includes accessing attributes and
relationships of EO's, modifying EOs in any way, and committing your in-memory
transaction.
the dbcontext lock only protects the dbcontext, i
It looks like one has to have faith that EC must be locked/unlocked in any
case. Referring the following post...
http://www.mail-archive.com/webobjects-dev@lists.apple.com/msg21704.html
If EOEditingContext puts lock on DBContext somewhere inside saveChanges(), and
after success/failure of the o
Thank you very much sir. Now I won't forget the lesson for the rest of my life.
:)
Another question, is it safe not to lock EC if I'm sure I'm not gonna modify
the objects fetched using that EC the rest of the Application Life Cycle?
Farrukh
On 2010-05-01, at 8:11 PM, Chuck Hill wrote:
>
> O
On May 1, 2010, at 10:01 AM, Farrukh Ijaz wrote:
Is it legal to perform saveChanges/revert on EOEditingContext in a
traditional JDBC transaction commit/rollback style?
EOEditingContext ec = // Got EOEditingContext from Somewhere...
// ec is not locked...
Find gun.
Shoot self in head.
Don't
