On Fri, 17 Dec 2004 14:35:56 +0100, Armin Waibel <[EMAIL PROTECTED]> wrote: > Hi Oliver, > > Oliver Zeigermann wrote: > > On Mon, 13 Dec 2004 12:43:59 +0100, Armin Waibel <[EMAIL PROTECTED]> wrote: > > > >>The OTM layer is alpha state, so there will be much of "unchecked" code. > >>Currently nobody works on OTM and for OJB 1.1 we try to move most > >>services (e.g. locking,...) to the kernel (org.apache.broker.*). You > >>could find the "old moved" locking version in org.apache.broker.locking.* > >>This version (used by odmg-api) isn't as smart as the OTM version (any > >>help to include the LockWaitStrategy from OTM is appreciated ;-)). > > > > > > Thanks. This makes more sense, I still do not understand what > > SerializableStrategy is doing?! > > well, seems that this strategy lock the object for one entity other > entity can't get read or write lock, only the owner entity can upgrade > lock. Think in this case read==write, it only allows one entity to work > on an object at the same time.
Yes, but why? I seem to remember that two phase locking with read/write locks for all transactions is just enough. Or is this to be sure that no other transactions with lower isolation inferfere? > OJB has the following requirements: > - pluggable components, e.g. when OJB run in j2ee compatible appServer > we need a JMS based locking solution (run in clustered environments) Hmmm. Could you explain this a bit? How is this suppost to work? > - the timeout strategy needs to be pluggable, because in j2ee compatible > appServer (OJB was used in session beans) it's AFAIK not allowed to > manage Threads (it's done by the container). Threads managed (blocked) using JMS? Is this the idea? Hmmm, I understand for complex applications there is no other way than to manage threads even in J2EE. I thought everyone does?! > - OJB allows to specify the used locking strategy generally and per > class, so the LockManager should be able to deal with different strategy. This would be no problem. The lock manager supports both blocking and non-blocking requests. I would be glad if you had a look at the stuff and tell me if you think it is suitable. Oliver --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
