On Thu, 09 Dec 2004 10:39:31 +0100, Armin Waibel <[EMAIL PROTECTED]> wrote: > Hi Oliver, > > Oliver Zeigermann wrote: > > >>can anyone tell me if OJB is able to find out that a certain SQL > >>exception really is a deadlock exception and maps it to another common > >>one (DeadlockException)? This would be very helpful to repeat a > >>deadlocked transaction. I found no code in OJB that might do such a > >>job. > >> > > You are right. OJB wraps all SQLException as > PersistenceBrokerSQLException (except key constraint errors here OJB use > a specific exception). See JdbcAccessImpl#executeInsert. PBSE is an > unchecked exception and with #getCause() you can extract the SQLException. > > > >>If there is nothing in OBJ the Jakarta Slide project has some initial > >>code that does this for some dbs. Maybe this could be integrated in > >>OJB? > >> > > hmm, I only found some code in PostgresRDBMSAdapter#createException. > Were can I find the common code for deadlock handling?
Until now code to detect an exception really is a deadlock exception is available for Postgres, MySQL, SQLServer and Sybase only. Slide also supports DB2 and Oracle, but the code for them still is missing. The rest of the code merely catches the DeadLockException at top level, rolls back the transaction, starts a new one and repeats the whole request. Slide also has some internal locking which can be used to either completely eliminate deadlocks (at the cost of no concurrency while writing) or at least limit its likelyhood. > > Is this just nonsense or is it that no one is interested? How do OJB > > users handle deadlocks? > > I think most people catch PersistenceBrokerSQLException to handle the > SQLException and the different SQLSTATE. > > It will be no problem to introduce a common method for handling > SQLException in Platform class based on the SQLSTATE of the > SQLException, e.g. > Platform#createException(SQLException e) > which return different unchecked exceptions inherited from PBSE (e.g. > KeyConstraintViolation, DeadlockException, TimeoutException, ...). > > Would this be helpful? Yes! However, it turned out that when using low isolation levels there may be constraint violations which would not occur if you had your transactions serializable. They would have to be treated just like a deadlock or "can not serialize error". As this really depends on your database schema and constraints I guess it is impossible to do this in a completely generic way. I have been told that Hibernate (2.1.7) supports a mapping with an (XML?) configuration file: http://forum.hibernate.org/viewtopic.php?p=2223974 Maybe as a default all of the Exceptions mentioned above should cause the transaction to be redone? On the other hand contraint violations really can indicate programming errors... I know it is always tricky to ask for new features without contributing. So, to get this going do you want me to prepare a patch for OJB which does exactly this: Introduce the createException method in the plattform class plus the exceptions and the initial code to feed it reasonably for Postgres, MySQL, SQLServer, and Sybase (is Sybase supported by OJB in the first place?)? Maybe as a seconed step there could be a configuration mapping file ala Spring or Hibernate? Oliver --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
