On Thu, Jul 12, 2001 at 07:24:11AM +0200, Gerald Richter wrote:
> I have one question about your Postgres patch:
>
> > sub close {
> > my $self = shift;
> >
> > if ($self->{rollback_on_destroy}) {
> > # we may as well be explicit about these things..
> > $self->{dbh}->rollback;
> > } elsif ($self->{commit}) {
> > $self->{dbh}->commit;
> > }
> > }
> >
> > (requires my earlier patch which sets rollback_on_destroy if
> > Transaction=1 was given)
> >
>
> Why do you need an extra 'rollback_on_destroy' ?
>
> Why can't you simply use commit ? (If we are allowed to commit, why
> shouldn't we rollback if anything went wrong?)
i get nervous about automatically committing on DESTROY.
I changed Store::Postgres to rollback if Transaction=>1 is given, and
they did not explicitly call insert(), update() or remove() (which do
a commit of their own).
The "official" Store::Postgres doesn't use the Transaction option, so
i hoped this wouldn't affect existing users.
Theoretically, you could give neither Transaction nor Commit, and you
would have an outstanding transaction, that you need to commit (or
rollback) yourself (outside Apache::Session). as far as i could tell,
this was the expected behaviour when Commit wasn't given. This, and
not affecting existing users, was the reason i didn't just use "if !Commit".
gerald, if the Apache::Session author has disappeared, i'm tempted to
just take/fork it and start "fixing" it.
--
- Gus
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
