On Feb 24, 2007, at 5:20 AM, Wolfram Stebel wrote:
I was running and rerunning a set of
functional tests. I was not stopping the app, but between each run I
would run a script to reset the data. Sigh. And part of the script,
Don't you use WOUnitTest? It helps setting up and tearing down
tests very
well, as far as i recall...
I now use TestNG for all my Java class unit testing. I never unit
test the UI, I never write components with enough Java or complex
enough Java to need unit testing. The tests I am referring to are
automated functional tests run through a browser. These are written
and run with Selenium. The script is part of a nightly integration
build. It is only run once in the integration build so it was not
causing problems there.
Now, without a doubt, it is time for beer.
Well, thats always a good idea :-)
Go and meet some WO-Specialists :-)
Sacha et al :-)
The LAST thing I want to do after a week like this is talk about
WO! :-)
Always enjoying your support
Your idiot, leading the way!
Chuck
On Feb 21, 2007, at 3:04 PM, Chuck Hill wrote:
Hi,
Some of you will recognize this extremely fun exception:
java.lang.IllegalStateException: rowDiffsForAttributes: snapshot in
com.webobjects.eoaccess.EODatabaseOperation {
_dbSnapshot = {};
...
this = "<com.foo.bar.DownloadLog a849b0 _EOIntegralKeyGlobalID
[DownloadLog (java.lang.Long)0]>"; }";
_globalID = _EOIntegralKeyGlobalID[DownloadLog (java.lang.Long)0];
_databaseOperator = "EODatabaseUpdateOperator"; }
does not contain value for attribute named downloadDate with
snapshot key: downloadDate
The stack trace is:
at
com.webobjects.eoaccess.EODatabaseOperation.rowDiffsForAttributes
(EODatabaseOperation.java:338)
at
com.webobjects.eoaccess.EODatabaseContext.createAdaptorOperationsFor
Da
tabaseOperationAttributes(EODatabaseContext.java:5373)
at
com.webobjects.eoaccess.EODatabaseContext.createAdaptorOperationsFor
Da
tabaseOperation(EODatabaseContext.java:5548)
at com.webobjects.eoaccess.EODatabaseContext.performChanges
(EODatabaseContext.java:6365)
at
com.webobjects.eocontrol.EOObjectStoreCoordinator.saveChangesInEditi
ng
Context(EOObjectStoreCoordinator.java:415)
at com.webobjects.eocontrol.EOEditingContext.saveChanges
(EOEditingContext.java:3226)
at net.global_village.eofextensions.ForgetfulEC.saveChanges
(ForgetfulEC.java:54)
at net.global_village.eofvalidation.EOEditingContext.saveChanges
(EOEditingContext.java:126)
at
net.global_village.eofvalidation.NotifyingEditingContext.saveChanges
(NotifyingEditingContext.java:159)
The exception is correct, the snapshot _dbSnapshot = {}; does not
contain any values, let alone the one it is looking for. I am not
completely sure of how this happens. It is not consistent so I
believe it to be caused by concurrent threads sending EOF
notifications interacting with the locked / unlocked state of
editing contexts.
The situation that I have that causes this exception is this: I
have a page that starts an import process. It spins off a thread
that handles the actual import. This thread has its own EC. The
first thing it does is to create a new DownloadLog to record the
start / status of the import process. While it is processing, it
periodically unlocks and re-locks the EC and does a refreshing
fetch on the download log so that it can see changes made in other
editing contexts.
Once this thread is started, and concurrent with its processing,
the app goes to a page that monitors all the download logs. This
was built using the AjaxGrid and refreshes every 30 seconds. At
each refresh it does a refreshing fetch. Of course, its EC is
unlocked between requests. It has a link to abort the import by
writing to the download log, though that is not being used when
this exception occurs.
Periodically the download processing thread will throw the above
exception while saving an update to the download log. My guess is
that the refreshing fetch is invalidating the snapshot that the EC
was referring to and it gets a null / empty dictionary for it as it
is still locked.
I fixed this (or at least I can't reproduce it anymore) by doing
ec.unlock(); ec.lock(); immediately before ec.saveChanges();. My
guess is that this allows the snapshot to get updated. I suspect
there is still a race condition in there where the a refreshing
fetch is done on the download load while saveChanges() is in
progress.
Does anyone know anything more about this or can you shed light on
what is happening and how you worked around it?
Cheers,
Chuck
--
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
Dipl. Inform. Wolfram Stebel, bugs&errors
Flutgrabenstr. 19, 35576 Wetzlar
Tel. 06441/47633
Mailto:[EMAIL PROTECTED]
Web: www.bugs-and-errors.de
--
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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
