Maciej Jaros | 1 Sep 08:42 2010
Picon

Re: Transaction nesting and savepoints

  At 2010-08-31 19:09, Aryeh Gregor wrote:
> On Tue, Aug 31, 2010 at 11:08 AM, Platonides<Platonides <at> gmail.com>  wrote:
>> I propose changing Database::begin() / commit() / rollback() to keep the
>> count in mTrxLevel and perform a savepoint instead of a BEGIN should it
>> be called inside another one.
>>
>> Savepoints are a way to perform partial rollbacks inside a bigger
>> transaction. They are supported by all our databases [5] [6] [7] [8] [9]
>> [10]. We shouldn't even have problems with our 4.0.30
>> servers, since its support was added in mysql 4.0.14 [11].
> I think there would be performance issues with this.  Specifically,
> there are a number of places where we do a commit because we need to
> release locks immediately to avoid contention.  It looks like the
> locks are held until the transaction commit when savepoints are used,
> so this might make us hold a lot of locks for much too long.
> DatabaseBase should definitely be DBMS-neutral here, though, and
> should not depend on MySQL's behavior.  I suggest that begin() check
> the transaction level, and if there's an open transaction, it should
> do an explicit commit() first and wfWarn().  This kind of thing is a
> bug -- it will lead to less atomicity than it looks like we have from
> casual code inspection, and these cases should be looked at and fixed
> if possible.

I think it still should be conscious decision and so those functions 
could use their first... hm... second parameter as the transaction name. 
For MS SQL you can simply use BEGIN TRANSACTION [name] (I think it would 
be more natural), for MySQL I guess savepoints should be used.

Regards,
Nux.
(Continue reading)

Aryeh Gregor | 1 Sep 17:03 2010
Picon

Re: Transaction nesting and savepoints

On Wed, Sep 1, 2010 at 2:42 AM, Maciej Jaros <egil <at> wp.pl> wrote:
> I think it still should be conscious decision and so those functions
> could use their first... hm... second parameter as the transaction name.
> For MS SQL you can simply use BEGIN TRANSACTION [name] (I think it would
> be more natural), for MySQL I guess savepoints should be used.

I'm not sure what you're saying here.  Are you suggesting some
solution where commit() does not actually always commit the current
transaction?  If so, as I said, this is a problem because it will
cause locks to be held for much too long in some cases.
Maciej Jaros | 1 Sep 20:13 2010
Picon

Re: Transaction nesting and savepoints

  At 2010-09-01 17:03, Aryeh Gregor wrote:
> On Wed, Sep 1, 2010 at 2:42 AM, Maciej Jaros<egil <at> wp.pl>  wrote:
>> I think it still should be conscious decision and so those functions
>> could use their first... hm... second parameter as the transaction name.
>> For MS SQL you can simply use BEGIN TRANSACTION [name] (I think it would
>> be more natural), for MySQL I guess savepoints should be used.
> I'm not sure what you're saying here.  Are you suggesting some
> solution where commit() does not actually always commit the current
> transaction?  If so, as I said, this is a problem because it will
> cause locks to be held for much too long in some cases.
Not exactly. If you know you can and should commit transaction called 
for example "article_update" then it's OK. If you want to commit 
"image_insert_and_update" then it's OK too. If you are making a commit 
for everything that is started then it doesn't seem OK as pointed out by 
Platonides in his example.
Jason A. Spiro | 1 Sep 21:56 2010
Picon

Re: latextwowki: latex to mediawiki translator

2010/8/30 asia Jędrzejewska-Szmek <asia <at> fuw.edu.pl>:
>
> I would like to announce latextwowiki -- a latex to mediawiki
> translator.
...
> The pre-alpha version can be
> downloaded from http://escher.fuw.edu.pl/git/latextwowiki.
...

Thank you for writing this.  How does it compare with the other tools
that can convert Latex to MediaWiki, such as pandoc?

--

-- 
Jason Spiro: software/web developer, packager, trainer, IT consultant.
I support Linux, UNIX, Windows, and more. Contact me to discuss your needs.
+1 (416) 992-3445 / www.jspiro.com

_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Aryeh Gregor | 1 Sep 22:53 2010
Picon

Re: Transaction nesting and savepoints

On Wed, Sep 1, 2010 at 2:13 PM, Maciej Jaros <egil <at> wp.pl> wrote:
> Not exactly. If you know you can and should commit transaction called
> for example "article_update" then it's OK. If you want to commit
> "image_insert_and_update" then it's OK too. If you are making a commit
> for everything that is started then it doesn't seem OK as pointed out by
> Platonides in his example.

When it comes to locks, you can't commit only some things and not
others, at least not on MySQL.  Locks are only released if you commit
everything, so to release locks, you do need to commit everything.  I
don't think we can avoid this, but we can raise warnings so that we
know where the places are, and see if we can figure out some way to
fix them -- like by moving the sensitive queries to the very end of
the transaction and removing the nested transaction.

I don't think naming is necessary.  As long as begin() is always
paired correctly with commit()/rollback(), we should be fine.  Adding
a name parameter would make sense as an error-catching measure,
though.
Platonides | 2 Sep 00:47 2010
Picon

Re: Transaction nesting and savepoints

Aryeh Gregor wrote:
> On Wed, Sep 1, 2010 at 2:42 AM, Maciej Jaros <egil <at> wp.pl> wrote:
>> I think it still should be conscious decision and so those functions
>> could use their first... hm... second parameter as the transaction name.
>> For MS SQL you can simply use BEGIN TRANSACTION [name] (I think it would
>> be more natural), for MySQL I guess savepoints should be used.
> 
> I'm not sure what you're saying here.  Are you suggesting some
> solution where commit() does not actually always commit the current
> transaction?  If so, as I said, this is a problem because it will
> cause locks to be held for much too long in some cases.

Is there some way to find out those points were the commit needs to be
there for lock freeing and not just for normal transaction finish ?
Aryeh Gregor | 2 Sep 01:04 2010
Picon

Re: Transaction nesting and savepoints

On Wed, Sep 1, 2010 at 6:47 PM, Platonides <Platonides <at> gmail.com> wrote:
> Is there some way to find out those points were the commit needs to be
> there for lock freeing and not just for normal transaction finish ?

Look at every single commit() and guess?  Alternatively, we could just
assume none of them are for releasing locks, skip them and see what
Domas comments out to fix the site when it breaks.  ;)
Christophe Henner | 2 Sep 12:01 2010
Picon

[HTML5] Improving Commons upload interface

Hi Everyone,

I searched the archives of both list and couldn't find any thread
about it. I could miss it, so sorry it it already has been discussed.

We all know that uploading a file on commons, and on Wikimedia, is
kind of tricky nowdays. However, this could be changed thanks to
HTML5.

HTML5 includes the drag and drop thingy that makes the uploads easier
and that can automatically fetch the EXIF datas. If we want we could
even allow the multiple drag and drop.

Anyway this could be a solution to look at, you can get more
information there :
http://hacks.mozilla.org/2009/12/firefox-36-fileapi-demo-reading-exif-data-from-a-local-jpeg-file/
and there : http://hacks.mozilla.org/2009/12/file-drag-and-drop-in-firefox-3-6/

All the best,

--

-- 
Christophe
Chad | 2 Sep 16:50 2010
Picon

Re: [HTML5] Improving Commons upload interface

On Thu, Sep 2, 2010 at 6:01 AM, Christophe Henner
<christophe.henner <at> gmail.com> wrote:
> Hi Everyone,
>
> I searched the archives of both list and couldn't find any thread
> about it. I could miss it, so sorry it it already has been discussed.
>
> We all know that uploading a file on commons, and on Wikimedia, is
> kind of tricky nowdays. However, this could be changed thanks to
> HTML5.
>
> HTML5 includes the drag and drop thingy that makes the uploads easier
> and that can automatically fetch the EXIF datas. If we want we could
> even allow the multiple drag and drop.
>
> Anyway this could be a solution to look at, you can get more
> information there :
> http://hacks.mozilla.org/2009/12/firefox-36-fileapi-demo-reading-exif-data-from-a-local-jpeg-file/
> and there : http://hacks.mozilla.org/2009/12/file-drag-and-drop-in-firefox-3-6/
>
> All the best,
>
> --
> Christophe
>

Keeping in mind that it won't work for everybody :)

http://caniuse.com/#feat=fileapi

(Continue reading)

Guillaume Paumier | 2 Sep 17:36 2010
Picon

Re: [HTML5] Improving Commons upload interface

Bonjour,

Le jeudi 02 septembre 2010 à 12:01 +0200, Christophe Henner a écrit :*
> 
> We all know that uploading a file on commons, and on Wikimedia, is
> kind of tricky nowdays. However, this could be changed thanks to
> HTML5.
> 
> HTML5 includes the drag and drop thingy that makes the uploads easier
> and that can automatically fetch the EXIF datas. If we want we could
> even allow the multiple drag and drop.

There are a lot of things we /could/ do, but only few we /can/ do with
limited resources. Unless you're offering to develop the feature
yourself :)

--

-- 
Guillaume Paumier
Product Manager, Multimedia Usability
Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Gmane