Just to make sure, the real service methods are getAvailableVDBs, getVDB, and possibly changeVDBStatus which can move to ConfigurationService. All the other methods are moving to VDBMetadata. I would be in favor of the threadlocal/session approach. VDBArchive/VDBMetadata objects should be heavily shared, so there is only an incremental memory cost. And as long as we are cleaning up our context appropriately there's no danger of a leak. ----- Original Message ----- From: "Ramesh Reddy" <rareddy(a)redhat.com&gt; To: teiid-dev(a)lists.jboss.org Sent: Thursday, December 3, 2009 11:52:11 AM GMT -06:00 US/Canada Central Subject: [teiid-dev] Re-working VDBService in JCA branch Steve, I am trying to see feasibility of getting rid of the VDB Service, metadata service and make the logged in user's VDBMetaData available in all the places that VDBService was used in JCA branch so that it is inline with other services in JCA branch. For its access I could use - static access (yuck..) - bean injection (like parameter passing, like now) - JNDI lookup - ThreadLocal (in the DQPWorkContext) where VDBMetadata will give you all the info needed on the VDB user logged in. I am leaning toward ThreadLocal, as it is non-intrusive on the APIs, not sure if increases any memory requirements. What do you think? Thanks Ramesh.. _______________________________________________ teiid-dev mailing list teiid-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/teiid-dev