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>
Sent: Thursday, December 3, 2009 11:52:11 AM GMT -06:00 US/Canada Central
Subject: [teiid-dev] Re-working VDBService in JCA branch
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?
teiid-dev mailing list