Tony Ng wrote:
> The main reason why the app server should implement the DataSource
> class is that it enables interposition when a component requests
> a JDBC connection:
>
> - it allows the application server to perform automatic sign-on to
> the database
> - returns a connection from app server's connection pool
> instead of contacting the JDBC driver
> - enlists the connection in the proper transaction with the
> Transaction Manager
>
> Once the connection is returned to the component, the component
> will bypass the app server and interact directly with the connection.
Is this "component" in a 3 tier environment?
If it can bypass the app server after the initial connection, so is the DataSource
object required only for the initial set up?
Are the transaction details passed via connection the the RM or TM as the case may
require?
>
>
> The DataSource object provided by the JDBC driver is more meant for
> 2-tier scenario where a client connects directly to the database.
> In an app server scenario, a component should use the DataSource object
> provided by the application server.
Can't the AppServer make use of the DataSource provided by DB vendor which is
registered in JNDI?
Why is it required for the App Server to implement the DataSource. As long as it can
access the methods via the DataSource interface provided by JDBC Driver?
I am still confused if the App Server (in EJB framework) is required to provide
implementation of DataSource (which is again vendor specific) or not?
Is it required to go through the Datasource->AppServer->DB for the subsequent
database calls?
Is this mandatory in all cases? (implementation of "DataSource" object by App Server)
I assime there might be special cases where an EJB compliant App Server would make use
of "DataSource" provided by DB vendors.
What if the following:
I have an App Server which does not implement any TM and makes use of an existing TM
like TP-Monitor, in that case I assume for handling distributed transactions the
DataSource can
directly talk to TM bypassing the AppServer.
On the other hand if the app server wishes to support distributed trnasactions by
iself then the DataSource is required to provide hooks for this which the JDBC 2.0
(std extensions)
addresses
I'm really trying to understand what kind of App Servers (EJB-Compliant) need to
implement DataSource object.
Why would the Database vendors like to integrate with app servers when they can
already provide distributed transaction support via standard mechanisms which can
co-exist with an App
Server if I am not wrong?
What is the rationale for DB vendors for going thru App Server in a 3-tier environment.
Finally to get a quick answer is this "DataSource" a mandatory feature for all
EJB-application servers .
Thanks for bearing with me.
Nishi.
>
>
> Thanks,
> Tony
>
> ------------
> Tony Ng [EMAIL PROTECTED]
> Enterprise Server Technologies 408-343-1648
> Java Software, Sun Microsystems Inc. 408-863-3195 fax
>
> [EMAIL PROTECTED] wrote:
> >
> > Hi,
> >
> > Trying to inderstand the new JDBC 2.0 standard extensions.
> >
> > 1. the Connection Poolng section (6) pg 17 para 2 says
> > "a middle tier server who wishes to implement connection pooling should provide a
>data source class"
> >
> > If the middle tier does not wish to support "DataSource" class who implements the
>"DataSource" and who registers it in the JNDI?
> >
> > 2. The document only says that app server need to implement "DataSource" and JDBC
>vendor "DataSource_intf", and does not explain as to why the app server need to
>implement this?
> > Can't the app server make use of DataSources registered in the JNDI by the
>Database?
> >
> > 3. Can't we bypass the app server once we connect to the database via JDBC,
>especially to handle distributed transactions?
> >
> > 4. If we have an DataSource (with XA support) registered in JNDI and a TM which
>can manage distributed transactions.
> > What exactly does the EJB framework need to handle to support application level
>transaction demaracation?
> > WHY?
> >
> > TIA,
> > Nishi.
> >
> >
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
