Hi,
Thanks to everyone who replied.
I have removed locking from all but the primary key from the entity
and this has remedied the problem. But I am concerned that this is
not correct and may cause other problems. It is not possible for the
this error to be handled by the user because it occurs within a web
service operation that does not provide persistent transactions. The
problem appears when the user is making a series of modifications to
one entity and I think it is due to that each transaction/
modification is being handled by a different instance of the
application whose object store has become dirty. So in addition to
reducing the locking attributes I have ensured that the
EOEditingContext refaults before each transaction. (I suspect only
one would be necessary.)
Cheers,
Corin.
On 25/07/2006, at 6:42 PM, shaun wrote:
Hi,
Corin Lawson wrote:
Hi List,
As volume has increased on our woapp so has the occurrence of
this particular error, below. I am using WO 5.2.4 with MySQL 5.0.
com.webobjects.eoaccess.EOGeneralAdaptorException:
updateValuesInRowDescribedByQualifier --
com.webobjects.jdbcadaptor.JDBCChannel method failed to update row
in database
at
com.webobjects.eoaccess.EODatabaseContext._exceptionWithDatabaseConte
xtI nformationAdded(EODatabaseContext.java:4685)
at
com.webobjects.eoaccess.EODatabaseContext.performChanges
(EODatabaseContext.java:6393)
at
com.webobjects.eocontrol.EOObjectStoreCoordinator.saveChangesInEditin
gCo ntext(EOObjectStoreCoordinator.java:415)
at com.webobjects.eocontrol.EOEditingContext.saveChanges
(EOEditingContext.java:3226)
We are currently looking into any network issues that could be
causing communication problems between the two servers (the one
with the woapp and the other with the database). Can anyone
provide light to this exception?
Optimistic locking failure perhaps. ie, One client trying to modify
a row that has been deleted or modified by another client. The more
clients accessing making modifications at the same time the more
likely this is to occur. Check which attributes are used for
locking on the entity that this occurs on to see if its likely
being modified by more than one client. I assume you are able to
pin-point the entity or the component at least. Catching this
exception, then getting the user to handle the modification somehow
is probably the solution you should consider rather than unchecking
attributes used for locking.
HTH.
- shaun
_______________________________________________
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]
