Re: [teiid-dev] Translators in the "vdb.xml" file.
On Tue, 2010-05-25 at 13:44 -0500, Michael Walker wrote:
Somewhat new to the translator nomenclature/architecture change...does
this mean that each VDB will have its own Translators, with their own
connection pools, and its own classloader, ensuring that VDBs will not
share translator instances among each other?
A translator is every thing except the connection semantics from
previous connector binding. The connection semantics are now called
"resource adapters" or "connectors (short for JCA connector).
The Translator code is deployed in the JBoss AS, however based on
configured properties it can instantiate a instance of this Translator,
which is used by the Teiid engine in same thread context to find
capabilities and translate into source specific queries.
The "resource adapter" is poolable, managable and possibly XA capable.
In the JDBC case this is nothing but a "data source" in an application
server. For other types of connections like LDAP and SF, we used JCA to
define the connection specifics.
So, the sharing model is Translators are VDB scoped, and connections
(can be) are shared.
If so, then this would be tremendously useful from a deployment
perspective. You could finally deploy a VDB and not have to choose
whether to use embedded binding properties or pre-existing properties
created by a pre-existing VDB. Deploying a new version of a translator
would not require ripping all previous versions out and rebuilding
them from scratch, which is very tedious and requires downtime. You
would have better guarantees about the level of service a connection
pool would provide, since there's no possibility of two VDBs sharing a
pool.
The argument is, since the Translator specific properties does not
change once the VDB is created, why not embed them along with the VDB so
that they are portable. Once we make them external, then we need to be
thinking about sharing the translators or how to migrate them between
environments.
Ramesh..