Message de Philippe Allart date 2008-01-16 11:15 :
Bonjour,
Est-ce que quelqu'un a eu écho de problèmes avec les accès concurrents à
OOo en mode serveur?
J'ai un cas d'erreur difficile à reproduire où un processus web demande
à OOo d'ouvrir un document modèle juste avant qu'un autre processus lui
demande de sauvegarder un docuement résultat. il y a donc deux deux
documents ouverts en même temps, mais dans des "desktop" différents. Un
des deux documents est vérolé.
J'ai retrouvé le résumé d'un fil de discussion en anglais autour de ce
sujet. Les répondeurs sont des chefs développeurs de Sun. Lire en fin de
ce mail.
C'est encore OOo V2.0 qui est utilisé. Je voudrais déjà savoir si ça
vaut le coup d'arrêter l'exploitation pour upgrader, où si le problème
est plus profond...
À mon avis la 2.0.x ne devient utilisable qu'à partir de la 2.0.3
La version initiale 2.0 ne devrait pas être utilisée, ni
profesionnellement ni en amateur.
______
Bernard
___ ___ ___ ___
thread : <http://www.mail-archive.com/[EMAIL PROTECTED]/msg00288.html>
We have a Java gui client that manages a pool of oo documents (xp
+oo.1.1..3) and executes oo-Basic macros on them via a UNO XDispatch
interface. We also have Java robotic processes that need to do the same.
While we can serialize attempts to execute macros in a single client (or
robotic) process, there is the chance that two robotic processes on the
same machine, sharing the same soffice.exe instance will attempt to
launch oo-basic macros on their documents simultaneously. The
documentation implies that this will cause oo-basic to fail.
-------------------
- is this so?
Yes.
- will XDispatch try to launch a basic macro on behalf of one
client while another is running on behalf of another client?
No.
- is there any defense against this?
Not built in ATM. There is nothing that prevents you from implanting a
service into the OOo process that receives your dispatch requests and
puts them into a queue.
- I imagine it would require some mutexes in the heart of the oo
side of XDispatch
Not really, because the same behavior results when everything is done in
one thread. While a macro is executed the Basic periodically checks the
message loop, mainly because painting and dialogs still should work.
Unfortunately at this step all events in the message queue are executed,
so also calls through the UNO bridge. We can't halt execution here until
the first dispatch is completely done because everything is done in the
same thread.
IMHO the culprit is that the VCL message queue doesn't allow to set a
message filter (f.e. that only paint events are allowed to be executed
at a certain point of time).
-- Mathias Bauer
--------------
to be secure i would suggest that you create an office pool and that use
one office for one robotic process. Everything else will probably result
in a deadlock or failure.
Jürgen Schmidt
--------------
it is a known fact that OOo has several multithreading problems. Most of
them reveal when using OOo API via remote UNO. Every single
multithreading problem can be considered a bug, but fixing all of them
is a rather complex task (due to the size and complexity of OOo code).
However, we're working on it... but even OOo 2.0 will still suffer from
multithreading issues.
For now, I strongly suggest not to use OOo in a multithreaded way.
Several workarounds for OOo's multithreading problems have been
discussed in the OOo mailing lists already. You should follow one of
these approaches.
Kai Sommerfeld
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
