Re: Intermittent Session Default Editing Context behaviour?
Re: Intermittent Session Default Editing Context behaviour?
- Subject: Re: Intermittent Session Default Editing Context behaviour?
- From: Chuck Hill <email@hidden>
- Date: Wed, 9 Jan 2008 17:29:00 -0800
Hi Peter,
On Jan 9, 2008, at 5:19 PM, Miguel Arroz wrote:
Hi!
Using saveChanges() and defaultEditingContext() in the same code
line is a really bad idea. The defaultEditingContext should only be
used to store long-living read-only objects.
To make changes, you should use local ECs. If you are modifying
and writing objects with the default EC, you'll quickly loose
control on what is on the default EC, and nothing will work at all.
An EC is like a sandbox, a very intelligent and powerful
transaction (I'll be beaten for using the T word, I know). So you
should keep its changes as local as possible. "It's a local EC for
local EOs".
Miguel has some good points, though I think that is not the cause of
your bug. If you do start using local (properly called peer) editing
context, you will need to lock them. If you are using Project
Wonder, ERXEC and friends will do this for you. If you are not using
Wonder, look for the MultiECLockManager. You can get this, and
WOSession subclass that uses it from our frameworks at: http://
sourceforge.net/projects/gvcsitemaker
I think the real cause of your problem is bad coding practices. That
call to refreshAllObjects() looks very odd. I have never seen anyone
do that before. Why are you doing that? It is certainly not
standard practice. I'd also take a long, hard look at your code
after reading the http://wiki.objectstyle.org/confluence/display/WO/
EOF-Using+EOF-The+EOF+Commandments
Chuck
On 2008/01/10, at 01:07, Peter Thompson wrote:
Hello,
We have an intermittent behaviour as follows:
We have an object (build via EOModeler) fetched into the session's
default editing context; which we are able to update successfully
via WO component bindings / java code via session
().defaultEditingContext().saveChanges(). We then do a session
().defaultEditingContext().refreshAllObjects(), but a subsequent
change to the object (via a "setter" in java code) is only
sometimes updated by a subsequent session().defaultEditingContext
().saveChanges(). This behaviour appears totally random - on
debugging we notice that sometimes the EditingContext's
"updatedObjects()" reflects the update done by the setter, and
sometimes it does not.
Is this a known problem?
Are we making assumptions that we shouldn't be i.e. is it correct
to assume that if we do...
1. fetch object into session's default editing context.
2. do updates on object via components / java code.
3. save object via:
session().defaultEditingContext().saveChanges();
session().defaultEditingContext().refreshAllObjects();
4. do further updates on object via java code.
5. save object again via:
session().defaultEditingContext().saveChanges();
session().defaultEditingContext().refreshAllObjects();
That step 5 should save the changes?
Appreciate any assistance you can give.
Cheers,
Peter
Peter Thompson
Senior Developer/Architect
Run The Red
www.runthered.com
===================================
E: email@hidden
M: + 64 21 241 3266 / + 64 27 441 3255
DDI: + 64 4 801 2806
P: +64 4 384 6880 F: +64 4 384 6875
Skype: peterwgtnnz
PO Box 11-703,
Level 2 Tadix House, 1 Blair Street,
Te Aro, Wellington 6011, New Zealand
===================================
--
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden