On Fri, 10 Dec 2004 13:16:24 +0100, Armin Waibel <[EMAIL PROTECTED]> wrote: > What is the "top level"? Slide itself or the app using Slide. If you run > a persistence layer in a managed environment (like a j2ee conform > appServer) it is not possible for the persistence layer to restart the > tx, because tx demarcation is handled by the container or bean or by the > client using UserTransaction(and tx could be a distributed tx). > So +1 for improving exception handling like you suggest, but -1 for all > stuff like automatic tx redo on persistence layer level. Or I'm wrong > and Slide could handle this in managed environments?
Agreed. Slide uses a UserTransaction, rolls it back and restarts it. This is not on the persistence layer. Thus OJB should not restart anything as well, but just throw the exception and the user needs to decide what is to be done. > > > 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. > > > > PB-api only supports optimistic locking. The odmg-api supports > pessimistic + optimistic locking (with configurable lock modes). > Pessimistic locking should be able to prevent DB deadlock (dependent on > odmg lock mode and DB lock mode). I can imagine scenarios when pessimistic (blocking) locks in the persistence layer can cause distributed (unresolvable) deadlocks. This can be when the DB has more coase grain locks than the persistence code or when there are transactions that do not use the persistence layer at all. > > 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? > > see beginning of response, maybe I misunderstand you ;-) Agreed. > > 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?)? > > +1 this will great! Will try, it might take some time... > > Maybe as a seconed step > > there could be a configuration mapping file ala Spring or Hibernate? > > > > +1 This could be an option for OJB 1.1 Considering what you said, you could just throw the exceptions and the user decides if he/she wants to redo the transaction or if it is a real programming error. This way there would be no need for a configurable mapping... Oliver --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
