Hi again, Max Rydahl Andersen wrote: > Greayt! :) > > Just some small questions from me on the answers :) > > "Maintains single identities for objects returned from queries " > Jakarta OJB: Yes.. > > 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. 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. > > 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? cheers, Thomas -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
