> 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.
So, the answer is: slide's doing the right thing, 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).
>
> 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.
>
> 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
:-)
>
> > 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.
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.
Michael
