Re: AW: jca adapter for (MySQL)DB

No, it does not replace XA. But it gets you quite some steps closer to XA
than you could without using a connector. My response is only referring to
the JDBC api, not to anything for which you could write a connector. If I
would try to generalize the properties that makes this possible for JDBC,
but not necessarily for any EIS, it would go something like:

An api that has the concept of a local transaction, where it would make
sense to apply the programming model for J2EE, when wrapping it in a
connector:
- dis-allow a call to begin/commit/rollback operations( or their
counterparties) of the connection interface while in a JTA transaction.
- Program the resource adapter to call these methods as the implementation
of the start / end transaction callback methods.

What makes an EIS dis-qualified? Well, if each operation is executed as an
atomic transaction, the EIS would not lend itself to the J2EE programming
model. If the EIS provides a concept of local transactions, whit an implicit
or explicit begin-operation and explicit commit and rollback operation, it
would likely qualify.

/Johan

Den 03-08-08 21.14, skrev "Ramakrishna Srinivasa"
<[email protected]>:

> I wonder if it possible to do like this. When the underlying Database/EIS
> System doesnt support XA , how is possible to achieve it with a JCA Adapter.
> For example SAP by itself doesnt support 2PC. Do you mean to say that a JCA
> Adapter for SAP can support 2PC ? In that case who will store the data which
> is uncommitted , should the Adapter take care of this?
>
> I am sorry, if I misinterpreted your answer.
>
> //Ramki.
>
> -----Original Message-----
> From: A public list for J2EE Connector architecture interest. on behalf of
> Johan Eltes
> Sent: Fri 8/8/2003 10:05 PM
> To: [email protected]
> Cc:
> Subject: Re: AW: jca adapter for (MySQL)DB
>
>
>
> To some applications, it could be of value to wrap a none-XA JDBC driver
> with an XA connector to mimic XA by deferring the commit/rollback call to
> the wrapped JDBC driver until the end of the jta transaction. It is far from
> XA but may be sufficient for the application at hand. I guess MySQL doesn't
> support XA?
>
> /Johan
>
>
> Den 03-08-08 20.38, skrev "Ram Jeyaraman" <[email protected]>:
>
>> It is important to separate out SPIs and APIs to understand the relationship
>> between JDBC and Connectors.
>>
>> JDBC is primarily an API, and Connectors is primarily an SPI. CCI is just
>> only
>> type of an API a Connector can expose, JMS is another, and so on.
>>
>> At the system level, the JDBC driver contracts and the Connector contracts
>> are
>> very similar. That is the reason why some vendors choose to implement JDBC
>> driver as a Connector and expose JDBC as an API to the application.
>>
>> Really from the application perspective, it does not matter, whether the JDBC
>> API is exposed via a JDBC driver or a Connector. thanks.
>>
>> ===========================================================================
>> To unsubscribe, send email to [email protected] and include in the body
>> of the message "signoff CONNECTOR-INTEREST".  For general help, send email to
>> [email protected] and include in the body of the message "help".
>
> ===========================================================================
> To unsubscribe, send email to [email protected] and include in the body
> of the message "signoff CONNECTOR-INTEREST".  For general help, send email to
> [email protected] and include in the body of the message "help".
>
>

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff CONNECTOR-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".