> As I mentioned before:
> If you are using the PB API, there is no protection of any kind. thread
> 1 and two are working on exactly the same instance and there is no write
> lock mechanism.
> Thus X will be 23 after commit of thread 1 and also after commit of
thread2.
>
> On the PB level you can work with optimistic locking to detect
> modifications by other threads.

Hmm - how ? When are the values for optimistic lock (version or timestamp)
used to check if someone have had a "old" write ?

If Thread 1 and Thread 2 is actually working on the same instance of Object
X then their version/timestamp would be the same,
thus by effect disabling optimistic lock detection :(

It will be correct if the values when Thread 2 commits - but what if some
thread try to load the Object X again, what values will
optimistic version/timestamp have then ?

Am i babling or making my self somewhat clear ? :)

> >
> >>But as many users expect this kind of integrity also adressed on the PB
> >>level we will have a new "one cache per broker" approach soon.
> >
> >
> > When is "soon" ?  :)
>
> Don't know! If someone volunteers it could be fixed tomorrow...

Ok - I volunteer, what should I do ? (hmmm - guess that volunteer has to
know the code better than me :)

> > One particular "construct" I would like to do is: SELECT X.* from X,Y
where
> > x.date > y.fromdate and x.date < y.todate
> > and then have X's returned from this query. It looks like
QueryByCriteria
> > can do something like this - but only criteria for X is allowed. How is
the
> > join with Y specified ?
>
> The query by criteria stuff does support path expressions
> that is something like "x.myY.fromdate" or "x.myY.todate"
> It will generate the correct join statement.
>
> But it is not possible to use QueryByCriteria in the above way if there
> is no x.My reference.

And references are somewhat "evil" from my point of view :)
I like to have them defined in the metamodel, but I do not like them to be
automatically fetched.
And using proxies is also not an option as I want to send the "object graph"
to a "remote"-site (e.g. client) where
there is no knowledge of a PersistenceBroker.

> But it is possible to use a QueryBySql instead. You can use QueryBySql
> to perform arbitrary SQL code. You only have to ensure that the columns
> of the returned resultset match to the columns declared in the
> class-descriptor for X.

Hey - then I can use "any" kind of sql to load objects :)

> >
> > Even better/more flexible could be to be able to state: SELECT X.*, Y.*
from
> > X,Y where x.date > y.fromdate and x.date < y.todate
> > And then have OBJ return a list of pairs of objects of X and Y class.
> >
>
> This is not possible.

No, but it sure would be nice - would'n'it ?

/max


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to