Hey
Nishi Nidamarty wrote:
> > 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?
Yes.
> If it can bypass the app server after the initial connection, so is the DataSource
>object required only for the initial set up?
It is used for acquiring Connections. This is done often or seldom
depending on the nature of the DataSource. If it is pooled the
Connection is typically returned ASAP.
> Are the transaction details passed via connection the the RM or TM as the case may
>require?
No, they are passed through the XAResource interface. Check the JTA API
for details. Also, be sure to read section 4.2 in the JDBC 2.0 spec.
Very illustrative.
> > 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?
After having rechecked both the JDBC2.0 and JTA1.0 specs I cannot find
any reason for the App Server to provide the DataSource implementation.
Someone else has a good reason?? It seems like the db vendor can provide
this just as well.
> Is it required to go through the Datasource->AppServer->DB for the subsequent
>database calls?
If AppServer implements the DataSource interface it is likely to be only
a wrapper for the DB-provided DataSource interface, i.e.:
"DataSource"->AppServer-impl.->DB-impl.->DB
> I assime there might be special cases where an EJB compliant App Server would make
>use of "DataSource" provided by DB vendors.
I'd say yes. I'm not sure what an AppServer provided implementation
would do actually. All things seems to be implementable by the DB
vendor, i.e.:
* Provide XA-interface
* Provide Connections to the DB
I mean, DataSource's doesn't do that much more...
> 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.
That seems likely, yes.
>
> 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
Through the XADataSource,XAConnection and JTA API XAResource interfaces,
yes.
> 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.
I have no idea. I too am somewhat confused about the reasons for doing
this.
If someone could shed some light on this that would be much appreciated
:-)
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
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".
