Hi again, <snip> > > What happens if thread 1 reads object X, changes X.value to 42 > thread 2 reads object X (what is the value here ? - thread 1 has not yet > commited, but the persistencebroker is sharing the same cache) > thread 2 changes X.value to 23 > thread 1 commits > thread 2 commits > > what is the value of X.value >
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. If you are working with ODMG transactions the situation is quite different: thread 1 will request a WRITE lock in order to modify X. As no other thread is active this lock will be granted and X is changed to 42. thread 2 tries to obtain a second WRITE lock on X. But this is forbidden for all ODMG lock levels! Thus a LockNotGrantedException will be thrown. On commiting of the tread 1 transaction X is 42. The ODMG Lockmanagement does work also in C/S where OJB runs on multiple VMs. There is a distributed Lockmanagement that maintains locks across all OJB servers in a cluster. There is also a cache synchronization mechanism that informs all caches about the change of X! > >>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... <snip> >> >>Why do you think that you need special SQL code generated? > > > The "first" reason is just to see how flexible the interface to OJB is - if > the code at runtime > is not bound to have Class X in table Y at all times then "real JDBC work" > should not be needed. exactly > > 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. 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. > > 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. You might use OJB ReportQueries to build such a solution. 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]>
