On Feb 6, 2004, at 4:06 AM, Vassilis Raxenidis wrote:
> My problem is that I want to be sure that the object is deleted. The
> for this is that the object must be processed if and only if it is
> successfully deleted from db. If for any reason the message is not
> then it will not be processed and should remain in db until the next
> polling. This technique will avoid the need for checking if a new
> object is an undeleted one and processed.
> Of course if no exception is
> thrown on commitChanges() call, it is safe to consider the object as
> deleted. But what happens if an exception is thrown when the
> is called. In such a case how can I be sure whether the object is
> deleted or
"DataContext.commitChanges" never throws an exception after a
successful commit. So you can rely on it. Here is some details.
Places where it does throw and exception are:
1. Object validation (in Cayenne 1.1, but not 1.0) - this happens
before the actual DB commit starts, and therefore means that your
object has not been deleted.
2. During DB commit - if a DB-level error occurred - in this case DB
transaction is rolled back, "undeleting" your object.
Places where things can still mess up are:
1. If you are running MySQL or other database with no real DB
transactions so "rollback" has no effect. I don't think Cayenne can
help here - switching to a real DB maybe the best option.
2. You enabled DataContext transaction events and registered your own
listeners. In this case you have control over the behavior of your
listeners and it is up to you to ensure consistency.
This archive was generated by hypermail 2.0.0 : Fri Feb 06 2004 - 13:53:31 EST