Yes, you're right. We have in the past restricted advance function to scenarios which utilize a config file, but I can see an issue with restricting this function to a managed environment. I think the attribute fits a lot better on DataSource and keeps things cleaner, but we should probably add it to Config for now and revisit this as part of a larger review of the config later. We put a lot of work into keeping the config file simple and intuitive, so I'd hate to see it explode into something unwieldy.
Anyway, I'll send in a patch shortly. Brent On 7/10/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
That seems not quite right since users can avoid DataSource altogether by passing in their own connection. Brent Daniel wrote: > It might be a little cleaner if we break DataSource out as its own > element and stick a "managedtx" attribute on it. > > On 7/10/06, Kevin Williams <[EMAIL PROTECTED]> wrote: > >> Yes. I think an addition to the config model is most consistent. Maybe >> an attribute on Config itself? >> >> Brent Daniel wrote: >> >> > Kevin, >> > >> > It looks like the support in the runtime is still there. I'm not >> > sure where the user API should be exposed, though. DASFactory would >> > seem like the most likely place, but that would give us some API >> > explosion there (three extra methods for each one that currently takes >> > a Connection.) I would suggest that we keep it out of the API, and >> > require the behavior to be specified in the config (we've done this >> > for other advanced scenarios.) Any thoughts? >> > >> > Brent >> > >> > On 7/10/06, Kevin Williams <[EMAIL PROTECTED]> wrote: >> > >> >> The DAS must be able to participate in external transactions. >> Although >> >> by default it will perform commit/rollback on the connection, clients >> >> should be able to put the DAS in a mode where it will not perform >> these >> >> actions when some external agent is responsible for managing the >> >> transaction. >> >> >> >> The DAS used to support this with an API on the command but we >> lost this >> >> when we refactored the interface to remove config-related items. I >> >> think it would be best to add this capability back now as part of our >> >> config model. >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> > >> > >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
