Re: [Wonder-disc] ERXEC and locking
IIRC ERXEC is locked when you touch any of its methods. Unlocking happens *only* when ERXEC.unlockAllContextsForCurrentThread() is called. You can see where that is called in the source code. On Jul 11, 2012, at 6:56 AM, Matteo Centro wrote: > From some experimentation it looks like that even in Session.terminate locks > are automagically generated even without explicit lock/unlock. > > Any thoughts? > > > Matteo > > On Tue, Jul 10, 2012 at 9:33 AM, Cheong Hee (Gmail) wrote: > I think you are right or at least this is the impression I had the last time > on this subject. I plan to move from MultiEC locking manager to ERXEC ec. > As usual, I could be wrong.. > > - Original Message - > From: Matteo Centro > To: Paul Dunkler > Cc: webobjects-dev@lists.apple.com Dev Apple ; Wonder Project > Sent: Monday, July 09, 2012 6:47 PM > Subject: Re: [Wonder-disc] ERXEC and locking > > Actually I noticed that removing all the locks (even the forgotten ones) > seems to have solved the problem... I had 10 unique users on 22 instances > running for a day and no deadlocks. > > Any thoughts about stuff that is done in the Session.terminate? I need to do > some cleanup if the session terminates, do I get automatic lock unlock in > that scenario or the termination happens in a separate thread and so I have > to manually lock/unlock? > > Thanks, > > > Matteo > > On Mon, Jul 9, 2012 at 12:19 PM, Paul Dunkler > wrote: >> I recently "Wonderized" a legacy WO application and I have a strange race >> condition that happens very rarely and only under extremely high load. >> Application extends ERXApplication, Session extends ERXSession and so on, I >> removed all "new EOEditingContext()" and replaced them with >> ERXEC.newEditingContext() >> but >> I forgot to remove some ec.lock() and ec.unlock() >> >> I am quite convinced that removing all locks and unlocks will bring me to a >> non deadlocking situation but I still want some reassurements >> I read a lot of stuff and I'm here to ask to you gurus a final word on the >> locking rule I inferred from what I read: >> >> If you always use ERXEC you can safely remove all lock and unlocks except >> for stuff that happen in background threads... >> >> Is it true? > > I think yes, its true. We are actually using Wonder Editing Contexts only and > do not have any other locking stuff. Everything runs fine. > >> >> What about stuff that happens in session.terminate()? I would say that it >> should have explicit lock/unlocks but any opinions are welcome. >> >> Thanks, >> >> >> Matteo >> -- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ >> Wonder-disc mailing list >> wonder-d...@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wonder-disc > > -- > Mit freundlichen Grüßen > > Paul Dunkler > > > > > > - > XYRALITY GmbH • Friedensallee 290 • 22763 Hamburg > Paul Dunkler • Technical Director > Mail: paul.dunk...@xyrality.com > Tel: +49 (0) 40 35 73 001 41 > Mobil: +49 (0) 151 252 228 42 > Fax: +49 (0) 40 35 73 001 99 > Web: http://www.xyrality.com/ > Registergericht: Hamburg HRB 115332 > Geschäftsführer: Sven Ossenbrüggen & Alexander Spohr > - > > > > > ___ > 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: > https://lists.apple.com/mailman/options/webobjects-dev/chng34%40gmail.com > > This email sent to chn...@gmail.com > > > ___ > 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: > https://lists.apple.com/mailman/options/webobjects-dev/kelleherk%40gmail.com > > This email sent to kelleh...@gmail.com ___ 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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [Wonder-disc] ERXEC and locking
>From some experimentation it looks like that even in Session.terminate locks are automagically generated even without explicit lock/unlock. Any thoughts? Matteo On Tue, Jul 10, 2012 at 9:33 AM, Cheong Hee (Gmail) wrote: > ** > I think you are right or at least this is the impression I had the last > time on this subject. I plan to move from MultiEC locking manager to > ERXEC ec. As usual, I could be wrong.. > > > - Original Message - > *From:* Matteo Centro > *To:* Paul Dunkler > *Cc:* webobjects-dev@lists.apple.com Dev > Apple; Wonder > Project > *Sent:* Monday, July 09, 2012 6:47 PM > *Subject:* Re: [Wonder-disc] ERXEC and locking > > Actually I noticed that removing all the locks (even the forgotten ones) > seems to have solved the problem... I had 10 unique users on 22 > instances running for a day and no deadlocks. > > Any thoughts about stuff that is done in the Session.terminate? I need to > do some cleanup if the session terminates, do I get automatic lock unlock > in that scenario or the termination happens in a separate thread and so I > have to manually lock/unlock? > > Thanks, > > > Matteo > > On Mon, Jul 9, 2012 at 12:19 PM, Paul Dunkler > wrote: > >> I recently "Wonderized" a legacy WO application and I have a strange >> race condition that happens very rarely and only under extremely high load. >> Application extends ERXApplication, Session extends ERXSession and so on, >> I removed all "new EOEditingContext()" and replaced them with >> ERXEC.newEditingContext() >> but >> I forgot to remove some ec.lock() and ec.unlock() >> >> I am quite convinced that removing all locks and unlocks will bring me to >> a non deadlocking situation but I still want some reassurements >> I read a lot of stuff and I'm here to ask to you gurus a final word on >> the locking rule I inferred from what I read: >> >> If you always use ERXEC you can safely remove all lock and unlocks except >> for stuff that happen in background threads... >> >> >> Is it true? >> >> >> I think yes, its true. We are actually using Wonder Editing Contexts only >> and do not have any other locking stuff. Everything runs fine. >> >> >> What about stuff that happens in session.terminate()? I would say that it >> should have explicit lock/unlocks but any opinions are welcome. >> >> Thanks, >> >> >> Matteo >> >> -- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ >> Wonder-disc mailing list >> wonder-d...@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wonder-disc >> >> >> -- >> Mit freundlichen Grüßen >> >> Paul Dunkler >> >> >> >> >> >> - >> XYRALITY GmbH • Friedensallee 290 • 22763 Hamburg >> Paul Dunkler • Technical Director >> Mail: paul.dunk...@xyrality.com >> Tel: +49 (0) 40 35 73 001 41 >> Mobil: +49 (0) 151 252 228 42 >> Fax: +49 (0) 40 35 73 001 99 >> Web: http://www.xyrality.com/ >> Registergericht: Hamburg HRB 115332 >> Geschäftsführer: Sven Ossenbrüggen & Alexander Spohr >> - >> >> > -- > > ___ > 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: > https://lists.apple.com/mailman/options/webobjects-dev/chng34%40gmail.com > > This email sent to chn...@gmail.com > > <> ___ 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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [Wonder-disc] ERXEC and locking
I think you are right or at least this is the impression I had the last time on this subject. I plan to move from MultiEC locking manager to ERXEC ec. As usual, I could be wrong.. - Original Message - From: Matteo Centro To: Paul Dunkler Cc: webobjects-dev@lists.apple.com Dev Apple ; Wonder Project Sent: Monday, July 09, 2012 6:47 PM Subject: Re: [Wonder-disc] ERXEC and locking Actually I noticed that removing all the locks (even the forgotten ones) seems to have solved the problem... I had 10 unique users on 22 instances running for a day and no deadlocks. Any thoughts about stuff that is done in the Session.terminate? I need to do some cleanup if the session terminates, do I get automatic lock unlock in that scenario or the termination happens in a separate thread and so I have to manually lock/unlock? Thanks, Matteo On Mon, Jul 9, 2012 at 12:19 PM, Paul Dunkler wrote: I recently "Wonderized" a legacy WO application and I have a strange race condition that happens very rarely and only under extremely high load. Application extends ERXApplication, Session extends ERXSession and so on, I removed all "new EOEditingContext()" and replaced them with ERXEC.newEditingContext() but I forgot to remove some ec.lock() and ec.unlock() I am quite convinced that removing all locks and unlocks will bring me to a non deadlocking situation but I still want some reassurements I read a lot of stuff and I'm here to ask to you gurus a final word on the locking rule I inferred from what I read: If you always use ERXEC you can safely remove all lock and unlocks except for stuff that happen in background threads... Is it true? I think yes, its true. We are actually using Wonder Editing Contexts only and do not have any other locking stuff. Everything runs fine. What about stuff that happens in session.terminate()? I would say that it should have explicit lock/unlocks but any opinions are welcome. Thanks, Matteo -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Wonder-disc mailing list wonder-d...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wonder-disc -- Mit freundlichen Grüßen Paul Dunkler - XYRALITY GmbH • Friedensallee 290 • 22763 Hamburg Paul Dunkler • Technical Director Mail: paul.dunk...@xyrality.com Tel: +49 (0) 40 35 73 001 41 Mobil: +49 (0) 151 252 228 42 Fax: +49 (0) 40 35 73 001 99 Web: http://www.xyrality.com/ Registergericht: Hamburg HRB 115332 Geschäftsführer: Sven Ossenbrüggen & Alexander Spohr - -- ___ 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: https://lists.apple.com/mailman/options/webobjects-dev/chng34%40gmail.com This email sent to chn...@gmail.com <> ___ 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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [Wonder-disc] ERXEC and locking
Actually I noticed that removing all the locks (even the forgotten ones) seems to have solved the problem... I had 10 unique users on 22 instances running for a day and no deadlocks. Any thoughts about stuff that is done in the Session.terminate? I need to do some cleanup if the session terminates, do I get automatic lock unlock in that scenario or the termination happens in a separate thread and so I have to manually lock/unlock? Thanks, Matteo On Mon, Jul 9, 2012 at 12:19 PM, Paul Dunkler wrote: > I recently "Wonderized" a legacy WO application and I have a strange race > condition that happens very rarely and only under extremely high load. > Application extends ERXApplication, Session extends ERXSession and so on, > I removed all "new EOEditingContext()" and replaced them with > ERXEC.newEditingContext() > but > I forgot to remove some ec.lock() and ec.unlock() > > I am quite convinced that removing all locks and unlocks will bring me to > a non deadlocking situation but I still want some reassurements > I read a lot of stuff and I'm here to ask to you gurus a final word on the > locking rule I inferred from what I read: > > If you always use ERXEC you can safely remove all lock and unlocks except > for stuff that happen in background threads... > > > Is it true? > > > I think yes, its true. We are actually using Wonder Editing Contexts only > and do not have any other locking stuff. Everything runs fine. > > > What about stuff that happens in session.terminate()? I would say that it > should have explicit lock/unlocks but any opinions are welcome. > > Thanks, > > > Matteo > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ > Wonder-disc mailing list > wonder-d...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wonder-disc > > > -- > Mit freundlichen Grüßen > > Paul Dunkler > > > > > > - > XYRALITY GmbH • Friedensallee 290 • 22763 Hamburg > Paul Dunkler • Technical Director > Mail: paul.dunk...@xyrality.com > Tel: +49 (0) 40 35 73 001 41 > Mobil: +49 (0) 151 252 228 42 > Fax: +49 (0) 40 35 73 001 99 > Web: http://www.xyrality.com/ > Registergericht: Hamburg HRB 115332 > Geschäftsführer: Sven Ossenbrüggen & Alexander Spohr > - > > <> ___ 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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [Wonder-disc] ERXEC and locking
I recently "Wonderized" a legacy WO application and I have a strange race condition that happens very rarely and only under extremely high load.Application extends ERXApplication, Session extends ERXSession and so on, I removed all "new EOEditingContext()" and replaced them with ERXEC.newEditingContext() butI forgot to remove some ec.lock() and ec.unlock()I am quite convinced that removing all locks and unlocks will bring me to a non deadlocking situation but I still want some reassurements I read a lot of stuff and I'm here to ask to you gurus a final word on the locking rule I inferred from what I read:If you always use ERXEC you can safely remove all lock and unlocks except for stuff that happen in background threads... Is it true?I think yes, its true. We are actually using Wonder Editing Contexts only and do not have any other locking stuff. Everything runs fine.What about stuff that happens in session.terminate()? I would say that it should have explicit lock/unlocks but any opinions are welcome.Thanks, Matteo --Live Security Virtual ConferenceExclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___Wonder-disc mailing listwonder-d...@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wonder-disc --Mit freundlichen GrüßenPaul Dunkler-XYRALITY GmbH • Friedensallee 290 • 22763 HamburgPaul Dunkler • Technical DirectorMail: paul.dunk...@xyrality.com Tel: +49 (0) 40 35 73 001 41Mobil: +49 (0) 151 252 228 42Fax: +49 (0) 40 35 73 001 99Web: http://www.xyrality.com/Registergericht: Hamburg HRB 115332Geschäftsführer: Sven Ossenbrüggen & Alexander Spohr- ___ 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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
ERXEC and locking
Hi all, I recently "Wonderized" a legacy WO application and I have a strange race condition that happens very rarely and only under extremely high load. Application extends ERXApplication, Session extends ERXSession and so on, I removed all "new EOEditingContext()" and replaced them with ERXEC.newEditingContext() but I forgot to remove some ec.lock() and ec.unlock() I am quite convinced that removing all locks and unlocks will bring me to a non deadlocking situation but I still want some reassurements I read a lot of stuff and I'm here to ask to you gurus a final word on the locking rule I inferred from what I read: If you always use ERXEC you can safely remove all lock and unlocks except for stuff that happen in background threads... Is it true? What about stuff that happens in session.terminate()? I would say that it should have explicit lock/unlocks but any opinions are welcome. Thanks, Matteo ___ 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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ERXEC and locking
On Aug 19, 2009, at 9:55 AM, gsbr...@umich.edu wrote:
I am making a Wonder app, and I Wonder: I still should maybe lock
the ec before using it?
That depends on how you are using it. :-)
You still have to lock the EC before using it. ERXEC just prevents
leaving locked EC afters the RR loop. However, you can also set the
autoLock stuff to on
er.extensions.ERXEC.defaultAutomaticLockUnlock=true
in which case the EC will get automatically looked. As this can
lead to deadlocks I normally don´t recommend it, though.
Cheers, Anjo
I was lead to believe that ERXEC was a "Subclass that has every
public method overridden to support automatic lock/unlock handling
for you."
Only if you have this enabled:
er.extensions.ERXEC.safeLocking=true
(or er.extensions.ERXEC.defaultAutomaticLockUnlock=true, but I'd stick
with safeLocking)
However, the discussion here:
http://lists.apple.com/archives/webobjects-dev/2005//Aug/thrd2.html#00164
seems to say one is better off manually locking / unlocking the ec
( with try/catch/finally blocks ), and uhuh..don't you go and rely
on that auto-locking voodoo !
An update in 2007 :
http://lists.apple.com/archives/Webobjects-dev/2007/May/msg00578.html
There are a lot of messages on that page. You will have to be more
specific if you want me to read them. :-)
Is that the latest word on the subject? I know things change over
time, which is often a good thing.
Where is the truth? in the Wonder documentation? ; > o
Is it safe to summarize : ?
1. er.extensions.ERXEC.safeLocking=true
2. Profit
A Wonder application that sets the property
er.extensions.ERXEC.safeLocking=true (this is equal to setting
several properties like the above mentioned one)
will be auto-magically locked and unlocked during the R-R loop. Any
other threads not on the R-R loop (like a java.util.TimerTask)
should use manual locking with the
try{ec.lock...}catch{}finally{ec.unlock} block.
That is correct.
Chuck
On Aug 13, 2009, at 11:38 AM, webobjects-dev-requ...@lists.apple.com
wrote:
Message: 7
Date: Thu, 13 Aug 2009 09:18:10 -0400
From: Mike Schrag
Subject: Re: ERXEC and locking
To: WebObjects-Dev List
Message-ID: <8b6dce65-ce5e-4a3c-bae2-1e33a3cf0...@mdimension.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
I have been watching Chuck's podcast - "WebObjects Quite Good
Practices", and I would like to make absolutely sure that I
understand this correctly.
Q: Is it true to say:
-
If I use ERXEC to create all my editingContexts, using:
EOEditingContext ec = ERXEC.newEditingContext();
then I do not have to worry about locking, it all happens
automagically.
assuming you have the appropriate properties set to autolock
Are the default settings to 'autolock'?
if by "default" you mean "with no Properties files," no, the default
is normal behavior. if by "default" you mean "the default Properties
file that WOLips makes," then yes. you should look in your Propeties
file to see if you have autolocking enabled.
Also, are the ECs that I create in the middle of an RR-loop safe?
yes
ms
--
gsbr...@umich.edu
___
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/chill%40global-village.net
This email sent to ch...@global-village.net
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
___
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
Re: ERXEC and locking
I am making a Wonder app, and I Wonder: I still should maybe
lock the ec before using it?
You still have to lock the EC before using it. ERXEC just
prevents leaving locked EC afters the RR loop. However, you can
also set the autoLock stuff to on
er.extensions.ERXEC.defaultAutomaticLockUnlock=true
in which case the EC will get automatically looked. As this can
lead to deadlocks I normally don´t recommend it, though.
Cheers, Anjo
I was lead to believe that ERXEC was a "Subclass that has every
public method overridden to support automatic lock/unlock
handling for you."
However, the discussion here:
http://lists.apple.com/archives/webobjects-dev/2005//Aug/thrd2.ht
ml#00164
seems to say one is better off manually locking / unlocking the
ec ( with try/catch/finally blocks ), and uhuh..don't you go
and rely on that auto-locking voodoo !
An update in 2007
: http://lists.apple.com/archives/Webobjects-dev/2007/May/msg0057
8.html
Is that the latest word on the subject? I know things change over
time, which is often a good thing.
Where is the truth? in the Wonder documentation? ; > o
Is it safe to summarize : ?
A Wonder application that sets the property
er.extensions.ERXEC.safeLocking=true (this is equal to setting
several properties like the above mentioned one)
will be auto-magically locked and unlocked during the R-R loop.
Any other threads not on the R-R loop (like
a java.util.TimerTask) should use manual locking with the
try{ec.lock...}catch{}finally{ec.unlock} block.
On Aug 13, 2009, at 11:38 AM,
webobjects-dev-requ...@lists.apple.com wrote:
Message: 7
Date: Thu, 13 Aug 2009 09:18:10 -0400
From: Mike Schrag
Subject: Re: ERXEC and locking
To: WebObjects-Dev List
Message-ID: <8b6dce65-ce5e-4a3c-bae2-1e33a3cf0...@mdimension.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed;
delsp=yes
I have been watching Chuck's podcast - "WebObjects Quite Good
Practices", and I would like to make absolutely sure that I
understand this correctly.
Q: Is it true to say:
-
If I use ERXEC to create all my editingContexts, using:
EOEditingContext ec = ERXEC.newEditingContext();
then I do not have to worry about locking, it all happens
automagically.
assuming you have the appropriate properties set to autolock
Are the default settings to 'autolock'?
if by "default" you mean "with no Properties files," no, the
default
is normal behavior. if by "default" you mean "the default
Properties
file that WOLips makes," then yes. you should look in your
Propeties
file to see if you have autolocking enabled.
Also, are the ECs that I create in the middle of an RR-loop safe?
yes
ms
--
gsbr...@umich.edu
___
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
Re: ERXEC and locking
I have been watching Chuck's podcast - "WebObjects Quite Good Practices", and I would like to make absolutely sure that I understand this correctly. Q: Is it true to say: - If I use ERXEC to create all my editingContexts, using: EOEditingContext ec = ERXEC.newEditingContext(); then I do not have to worry about locking, it all happens automagically. assuming you have the appropriate properties set to autolock Are the default settings to 'autolock'? if by "default" you mean "with no Properties files," no, the default is normal behavior. if by "default" you mean "the default Properties file that WOLips makes," then yes. you should look in your Propeties file to see if you have autolocking enabled. Also, are the ECs that I create in the middle of an RR-loop safe? yes 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 Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ERXEC and locking
On 13 Aug 2009, at 13:39, Mike Schrag wrote: I have been watching Chuck's podcast - "WebObjects Quite Good Practices", and I would like to make absolutely sure that I understand this correctly. Q: Is it true to say: - If I use ERXEC to create all my editingContexts, using: EOEditingContext ec = ERXEC.newEditingContext(); then I do not have to worry about locking, it all happens automagically. assuming you have the appropriate properties set to autolock Are the default settings to 'autolock'? Also, are the ECs that I create in the middle of an RR-loop safe? - That is absolutely correct... but (there is always a but, isn't it ;-) if you are not within a RR-loop (think of separate long running threads, ...) you have to lock manually. .. unless you use ERXRunnable Cool, I shall investigate. 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 Subscription: http://lists.apple.com/mailman/options/webobjects-dev/gowdy%40mac.com This email sent to go...@mac.com ___ 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
Re: ERXEC and locking
I have been watching Chuck's podcast - "WebObjects Quite Good Practices", and I would like to make absolutely sure that I understand this correctly. Q: Is it true to say: - If I use ERXEC to create all my editingContexts, using: EOEditingContext ec = ERXEC.newEditingContext(); then I do not have to worry about locking, it all happens automagically. assuming you have the appropriate properties set to autolock - That is absolutely correct... but (there is always a but, isn't it ;-) if you are not within a RR-loop (think of separate long running threads, ...) you have to lock manually. .. unless you use ERXRunnable 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 Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ERXEC and locking
Hi Mark, Am 13.08.2009 um 13:11 schrieb Mark Gowdy: Hi there, I have been watching Chuck's podcast - "WebObjects Quite Good Practices", and I would like to make absolutely sure that I understand this correctly. Q: Is it true to say: - If I use ERXEC to create all my editingContexts, using: EOEditingContext ec = ERXEC.newEditingContext(); then I do not have to worry about locking, it all happens automagically. - That is absolutely correct... but (there is always a but, isn't it ;-) if you are not within a RR-loop (think of separate long running threads, ...) you have to lock manually. jw Thanks, Mark ___ 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/jw%40oyosys.de This email sent to j...@oyosys.de smime.p7s Description: S/MIME cryptographic signature ___ 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
ERXEC and locking
Hi there, I have been watching Chuck's podcast - "WebObjects Quite Good Practices", and I would like to make absolutely sure that I understand this correctly. Q: Is it true to say: - If I use ERXEC to create all my editingContexts, using: EOEditingContext ec = ERXEC.newEditingContext(); then I do not have to worry about locking, it all happens automagically. - Thanks, Mark ___ 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
