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.
Could anyone explain? Anyway, it looks as if the locks never wait, right?
In org.apache.broker.locking package? Yep, this locking implementation hasn't lock wait strategy support (port from OTM-package needed).
Concerning the LockWaitStrategy I am currently extending Jakarta Commons Transaction to allow it's lock manager to allow both blocking and non blocking usage. I have just finished some sort of deadlock detection minus testing. All this and timeouts for active locks will most likely be in Commons Transaction 1.1.
If you are interested I will let you know as soon as it is in CVS for inspection and give more guidance.
Sure we are always interested in improving OJB. I will have a look at Commons Transaction ASAP (currently I'm really busy with OJB stuff).
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)
- 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).
- OJB allows to specify the used locking strategy generally and per class, so the LockManager should be able to deal with different strategy.
I haven't think much about #sleep versus #wait but I think using #wait will be more efficiently.
Well, sleep is not terminated by notify. This means the code will never know when a lock has really been released, but waits for a predetermined amount of time. Obviously, this unnecessarily limits concurrency. But maybe there is another reason for doing it this way which I am unaware of.
Completely agree with you.
regards, Armin
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
