Kay Ramme - Sun Germany - Hamburg wrote:

> Hi Oscar,
> 
> Oscar Picasso wrote:
>> Hi,
>> 
>> I have read several threads, without definitive answers, about the
>> current support for multhreading when using openoffice as a server.
>> 
>> Basically, I have a web application that, at user request, takes an
>> openoffice template, changes some text, based on the user input, and
>> generates a pdf file.
>> 
>> In this context is openoffice thread safe? If not was could be the
>> result of concurrently calling openoffice to populate a same template
>> on behalf of different requests?
> OOo tries to be thread-safe ... but unfortunately it is not really. If 
> you stress it, it dies ...
>> 
>> Crash? Performance? Confusion (mixing or changing the data?).
>> 
>> If the openoffice server is not thread safe, I thought about the web
>> requests calling openoffice from the command line. But in that case,
>> do concurrent calls use the same openoffice instance? Is it safe from
>> the data integrity point of view?
> Running one client at a time gives you good chances that the application 
> does not crash.
>> 
>> In short what is the safest way for openoffice to solve this use case.
> Good question ... the safest way is to use the "main-thread" for doing 
> operations in OOo, though this one is not directly reachable from 
> another process.

Well, in fact it nowadays is. There is a UNO service that can be called
with an object receiving a callback. This callback will happen in OOo's
main thread and by moving all code into this callback you will have your
code executed as if it was called from e.g. OOo's menu bar.

You still may have problems when your application is written in a
languagge using garbage collection as this can lead to desctructor calls
of OOo objects executed in the garbage collection thread.

Best regards,
Mathias

-- 
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[email protected]".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to