> > Some of the others mentions sesssion and application scope. > > How is OBJ handling this ? My guess is that the single identity is only true > > when using the same PersistenceBroker to get the objects, right ? > > > > The same object found by 2 threads/clients using different > > PersistenceBrokers gott'n from the same pool is not going to have the > > "uniques"-property, right ? Because if this is true two threads/clients > > would be able to step on each other toes, right ? > > > > Currently we have a global (that is VM wide) cache. Thus uniqueness is > maintained across *all* brokers. > > You are right that this may cause data integrity problems. These issues > are not addressed at the PB level, but on the Object transaction > management level. The ODMG transaction manager provides a pessimistic > lockmanager that is reponsible to prevent multiple concurrent writes to > a single object.
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 > 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" ? :) > > > > I think this one has been mentioned before but can't find the answer to it: > > > > Is there any way to programmatically (or statically) say: "Use this > > query/resultset to load objects of type X instead of the table/view > > mentioned in repository.xml ?" and if this is true then a subsequent > > question is: > > two ways to do this programmatically: > 1. change the ClassDescriptor for class X at runtime. (The > class-descriptor contains the mapping metadata for a given class) > 2. load all X instances into the cache with the special query, so > subsequent access to these instances will require no db lookup with the > default mapping. > > > > > Is there any way to programmatically (or statically) say: "Use this > > insert-statement to store objects of type X instead of the table/view > > mentioned in repository.xml ?" > > > > I see only one way: change the ClassDescriptor for class X at runtime. > > OJB provides also several mechanisms to interact with the persistence > mechanism. E.G RowReaders to influence red behaviour, FieldConversion to > provide type mappings between database columns and java attributes, > Instance Callbacks, etc. > > If there are very special problems to be addressed you can also ask OJB > for a JdbcConnection to do some "real JDBC work". > > 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. 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 ? 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. /max -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
