> Max Rydahl Andersen wrote:
> >>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 ?
>
> the optimistic lock values are checked on PB.store(X).
>
> >
> > 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 :(
>
> right. Optimistic Locking won't help in the scenario you describe.
Im sorry to hear this as this situation is exactly can happen often in our
application -
and we have to "discover" that another user/thread successfully saved
something before
the current user/thread completed its save ;(
> > 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 ? :)
>
> crystal clear!
Good, it was getting late and my brain was about to sleep :)
> >>>>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 :)
>
> Won't be too difficult. Currently the ObjectCacheFactory does only hand
> out a single instance ObjectCache to all PersistenceBrokers.
> This must be changed to have a unique Cache per Broker.
>
> We also have to make sure that there is no code relying on a singleton
> instance cache. This will include checking all references to
ObjectCache...
>
> We then need some additional synchronization bewteen the per broker
> caches. But I don't yet have a complete design for this issue.
Ok - and a short look at the sourcecode reveails that the ObjectCacheFactory
and ObjectCache is
actually very much singletons!
I just wonder how the testcases can be succesfull in the J2EE junit-tests.
Shouldn't they fail reliably if clients try to modify the same data ?
> >>>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.
>
> that is of course also possible. Just set the attribute
> auto-retrieve="false".
Well - that I know, but then they will be retreived when I try to access
them - And that I do not want on the client...se more below.
> > 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.
> >
>
> The OJB proxies are remote capable! You just have to run OJB in c/s mode
> to enable safely serializable proxies!
Yes - I know. But for security and performance reasons we would not like the
client to be able to retreive these objects remotly.
Arguments:
1. The client should only get data through our session beans which can check
for permissions on the data.
2. Relationships is required to be stated in the repository.xml before they
can be accessed as e.g. X.myY.fromData.
Thus by requirement clients can without asking for "permission" access
and accidently load all of the database - not good!
If just I could have a method like OJBHelper.fillInRelation(X, "myY", new
SomeCriteria()) which would insert or just return a collection for X's myY
field - but only those Y's that fullfills the SomeCriteria().
This would make it possible for my sessionmethods to gradually (under
control) fill in the object graph.
And if the client tries to access the relationships before they have been
filled in (under control) then I would throw an exception.
Am I still making my self clear ? :)
> >>>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 ?
> >
>
> Would be nice, but:
> It would safe only one additional broker call.
If there are 100 X's and e.g. on average 5 Y's matching an X - then the
above query would save 99 queris to the database!
> On the other hand it would require a complete redesign of the current
> Query implementation.
Nah, would it ? Is there so strong a binding on the Query implementation on
only returing one "column" of objects ?
> I have never missed this feature in real world projects. There have also
> been no user request asking for this feature.
It could save some queries to the database - so for performance reasons it
would be nice.
The alternative is to use ReportQueries as you stated - and then manually
load the X's and the Y's. But then all the "good" properties of the objects
such as uniqueness, optimistic locking and etc. would not automagically be
fullfilled - would it ? (Here i am concerned about what if the programmer
doing this forgot to fill in some part of X and Y by accident ? This would
not happen if OJB had the general methods for doing this (except if OJB's
developers forgot that little thing :)
/max
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
