nobody else seems to have an idea, so will will do some bla bla ;-)
I don't see any easy way to realize this completely within OJB. You can use MetadataManager "per thread metadata mode" to deal with different repository files. The "normal" repository file and you can load an additional "shrunk" repository were in class-descriptor all "big" fields removed. In your case a org class-descriptor only with PK and FK fields.
See javadoc of MetadataManager to see the details.
http://db.apache.org/ojb/api/org/apache/ojb/broker/metadata/MetadataManager.html
It is now possible to use a different object metadata profile (normal or shrunk repository) for each thread by calling
MM.loadProfile("shrunk");
Next call to PBF.createPersistenceBroker return a PB instance deals only with the limited 'org' version.
Only problem is the cache (I don't have a smart solution for this problem - any proposals are welcome ;-)). If you use a shared cache (e.g. ObjectCacheDefaultImpl) other threads with "normal" repository may get "dirty reads" of shrunked org objects. To avoid this you can specify a local cache for org class on class-descriptor level (e.g. ObjectCachePerBrokerImpl - not really good performance) or enable in OJB.properties the 'descriptorBasedCaches' property. Then OJB use separate caches for each cache defined class-descriptor based on ObjectCacheDescriptor instance
(object-cache element within class-descriptor). This means if you declare an object-cache within class-descriptor of 'org' you will end up in different cache instances for each profile ("normal", "shrunk").
Don't know if this is helpful ;-)
regards, Armin
Joe Germuska wrote:
I have a process which requires an extreme amount of overhead to manage with OJB that would be so simple to do in straight SQL. I'm hoping some OJB specialists can help me figure out how to tune this process.
For an application, we have a number of users who can log in to operate on behalf of their organizations. In the object model, there are two relevant objects: the organization (org for short) and the org-agent. The org is a fairly rich object, while the org-agent is merely the relationship between the agent's ID (a string) and the org itself.
I periodically get a data feed which essentially just maps agent ids to organization ids. In SQL, I'd just manage a single two-column table directly, and the process would be done in a matter of minutes. (About five minutes using a script I've written) However, in OJB, I seem to be dragging these heavy "org" objects around with everything I want to do, and it makes the thing take more like five hours.
I'm thinking that I could just run the direct-SQL script instead of using OJB, and then signal the application that its cache of these objects may be invalid. This is probably safe, in a practical sense, since the process is much more likely to insert new objects than change old ones, but I can't be certain of that.
The alternative would be to figure out a way to get OJB to accept updates to objects that may or may not have been loaded yet without performing a full load for each. I'm not totally clear on how OJB functions here either, but I think that if I make a new object with the same ID (primary key) as one for which OJB already has a cached instance, then OJB isn't real happy. Maybe I'm writing my tests wrong, but a few things I did to try to test this seem to bear it out.
Any advice or insight into how to achieve this best would be greatly appreciated...
Thanks Joe
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
