> > If you're using the JDBC store, the metadata added should be removed
when
> > the transaction itself is reverted. If they aren't, then there is a
problem.
> >
> > I think you should add some traces in start, rollback and commit in the
JDBC
> > and file stores to see if everything is done the way it should be. It
could
> > be a bug in the transaction manager.
>
> Ah. I see. As I said, I'm not aware of how the transactions stuff works
> in any useful detail. Anyway, see below (short version: it's the DB
> we're using).
>
>
> > Well, if you're using JDBC stores for everything, 3) should happen
without
> > the need for you to do anything.
> > The WebDAV servlet should do :
> > - start a transaction
> > - do all the operations needed by the put
> > - commit the transaction
> > If something fails in between, the entire transaction should be reverted
and
> > the namespace should end up in the same state it was before the PUT.
> >
> > Obviously, I like 3), since in theory it's not that hard to achieve with
the
> > appropriate stores :-)
>
> 'In theory' :-)
> If we're going to rely on the stores having transaction capabilities,
> then we really have to enforce this. But we can't do that realistically,
> because many things simply don't support transactions (a filesystem is a
> good example. It would be difficult at best to make a FileContentStore
> that acted correctly with respect to transactions). A hard problem.
Yes indeed. Without transactions, the store should use a best effort policy,
definitely.
> So, the answer is: slide's doing the right thing,
Well, I'll have to check that too, just to be sure :-)
> but the
> filecontentstore is broken w.r.t to transactions (not really fixable,
> but the important cases can be worked around), and the
> JDBCDescriptorsStore doesn't actually ensure that the database
> implements transactional capabilities (not really a problem. If it
> doesn't implement something, then it doesn't implement it - and there's
> nothing we can do about that).
Yes.
> > OTOH, it's totally overkill to try to do it ourselves, without special
> > capabilities at the store level.
>
> Agreed. It's not impossible, but it'd probably complicate much of the
> core slide code by an order of magnitude.
Yes.
> > Here, I think it's a problem with the TM, or maybe your database. Which
DB
> > are you using ? Is it supposed to handle transactions well ?
>
> We're using Mysql. It doesn't support transactions. At all.
> Well, supposedly the most recent version does, but only with special
> table-types, and that's just a really evil ugly hack as far as I can
> tell. Basically, it doesn't support transactions (it definately doesn't
> without extra stuff which slide doesn't do). Yes, it's quite silly to
> have a RDBMS without transaction support. Tell that to the mysql people
> :-)
Mmmm, doesn't look too good ...
I want a XADataSource :-)
> > > I've attached a (fairly trivial) fix that implements option 1, since
at
> > > this point that's my preferred option - Remy, feel free to commit it
(or
> > > ask me to) if you think this is the right thing to do.
> >
> > Go ahead. Anything which adds some robustness is good :)
> > BTW, you don't need to ask for the permission. If I don't like a patch
(or
> > if you don't like a patch), we can talk about it, and revert it if
> > necessary.
>
> I'll commit it then. I guess it's better than nothing.
A lot.
> I know I don't _need_ to ask for permission, but I don't just don't like
> committing things that I'm not completely sure about in most cases. This
> was probably something I should have committed anyway, though.
Whatever you like better :)
Remy
