OTM TransactionIsolation

[Oliver Zeigermann <ol...@gmail.com>]

Folks,

I am currently having a hard time to understand the different
implementations of TransactionIsolation machting the different
isolation levels.

Maybe they are obvious, but I am just not smart enough.

I also was wondering why TimeoutStrategy does not use Object#wait to
wait on a Object#notify upon release. Is this just a matter of taste
or is there anything that requires to use Thread#sleep?

Anyway, any hints are greatly appreciated.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

Re: OTM TransactionIsolation

[Oliver Zeigermann <ol...@gmail.com>]

On Fri, 17 Dec 2004 14:35:56 +0100, Armin Waibel <ar...@apache.org> wrote:
> Hi Oliver,
> 
> Oliver Zeigermann wrote:
> > On Mon, 13 Dec 2004 12:43:59 +0100, Armin Waibel <ar...@apache.org> 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: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

Re: OTM TransactionIsolation

[Armin Waibel <ar...@apache.org>]

Hi Oliver,

Oliver Zeigermann wrote:
> On Mon, 13 Dec 2004 12:43:59 +0100, Armin Waibel <ar...@apache.org> 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: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

Re: OTM TransactionIsolation

[Oliver Zeigermann <ol...@gmail.com>]

On Mon, 13 Dec 2004 12:43:59 +0100, Armin Waibel <ar...@apache.org> 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?! Could anyone explain? Anyway, it looks
as if the locks never wait, right?

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.

> 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.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

multithreaded PersistenceManager

[George Mardale <gi...@delsyne.ro>]

Hi everybody,

First of all, it's the fourth time I am asking for your opinion on this 
list, but until now no one replied. I don't know why this happens, since 
all my previous problems were related to simple OJB usage scenarios that 
failed to work in my case (just as an idea, we had to do some 
'workarounds' to avoid these really annoying problems, so they were 
never considered fixed).
I thought some of you have already experienced those problems. Maybe the 
problem was the fact that I am using OJB's JDO API (the plugin to 
JDORI). Who knows... The fact is that I found this particular API 
incredibly immature. I definitely don't recommend it to anybody. In my 
case, it is for sure the first and last time when I am using OJB's JDO 
API. I cannot say anything about PB API, but JDO API is a nightmare.

But anyway, I am sharing my problems again, maybe this time I will get 
lucky. So, as I said, I am using JDO API for developing a web 
application that needs multithreading support. My question is: what is 
the recommended approach for having multithreaded persistence managers?

We've already tried 2 approaches and both of them fail misserably:
1. we tried to get one persistence manager (for all clients) from the 
persistencemanagerfactory and set it to multithreaded (i.e., 
setMultithreaded(true)), but during concurrent access (i.e., multiple 
browser accessing same data at the same time), this fails with 
"transaction not active" or "transaction already started to commit"-like 
exceptions.
2. we tried to get one persistence manager per thread (i.e., each tread 
with its own persistence manager --- using ThreadLocal to store each 
thread's persistence manager). This works better than the first 
approach, but from time to time, we get "Instance .... not bound to the 
persistence manager of the query" exceptions. We couldn't create a 
step-by-step algorithm to reproduce the problem, but it seems that most 
of the times this exception appears after the appplication server (we 
use BEA"s WebLogic) switches the thread on which the web app runs (for 
us, new thread -> new persistence manager -> probably OJB's cache gets 
mixed up?!).

Any comments are greatly appreciated.

Thanks in advance,
George.

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

Re: OTM TransactionIsolation

[Armin Waibel <ar...@apache.org>]

Hi Oliver,

Oliver Zeigermann wrote:

> Folks,
> 
> I am currently having a hard time to understand the different
> implementations of TransactionIsolation machting the different
> isolation levels.
> 
> Maybe they are obvious, but I am just not smart enough.
> 
> I also was wondering why TimeoutStrategy does not use Object#wait to
> wait on a Object#notify upon release. Is this just a matter of taste
> or is there anything that requires to use Thread#sleep?
>

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 ;-)).

I haven't think much about #sleep versus #wait but I think using #wait 
will be more efficiently.

regards,
Armin

> Anyway, any hints are greatly appreciated.
> 
> Oliver
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org