[teiid-dev] Re-working VDBService in JCA branch

[Ramesh Reddy]

Thanks. That is exactly the model I am looking for. All individual VDB
specific calls move on to the VDBMetadata object itself and lifecycle
calls will be on the ConfigurationService (aka VDBRepository as in JCA
branch).

Ramesh..

On Thu, 2009-12-03 at 13:08 -0500, Steven Hawkins wrote:
> 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 at redhat.com>
> To: teiid-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev