Hi again Max, 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. > 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! > >>>>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. > > >>>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". > 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! > >>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 :) > Exactly! > >>>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. On the other hand it would require a complete redesign of the current Query implementation. I have never missed this feature in real world projects. There have also been no user request asking for this feature. cheers, Thomas > /max > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
