> On
> desktop computers everything works fine, but the slow ipaqs showed up
> some strange deadlock problem, which hasn't been detected before.
This tells me you need to check your JVM on the iPaq and see how it handles
things like threads.
> When a server thread receives a soap request from a client, it first has
> to call private methods in its own interface via soap for calculating
> the results.
This doesn't make much sense to me. If a server has received a request why
does it have to invoke methods on itself via SOAP unless it was to a
different SOAP service? If you are in one "service" or Java object just
invoke the method because you're already in the object, right?
This does not work, because the first soap request (from
> the client) has not been finished and no soap response has been sent
> back, so the interface class blocks method invokation (second internal
> soap request) until the first (client) soap request has really finished.
> That's why the client soap request result blocks forever -> deadlock.
This works in my desktop environment (JDK 1.3.1, Win 2000, Apache SOAP
v2.2). I can call out to other soap services and I can invoke the same
service from within a service via SOAP (not that I would ever want to).
Again, this tells me you need to look at the JVM you are using and see if
there are known threading issues. Why would the interface class block
additional invocations unless you were trying to synchronize?
> So the problem seems to be, that apache soap can't handle soap requests
> in parallel. My question is now: is this assumption correct or did we
> make any errors ?
You said it worked on your desktop, and it worked on my desktop. Bytecode
is the same right, so it does work...just apparently not on the iPaq. I
would check for issues with your JVM and make sure you really want to
self-invoke via SOAP.
> Is it in general impossible in java, to call two
> (different) methods on the same object from two threads ? I don't think
> so, but u never know :S
Sure you can, just watch out for synchronization issues (same as in any
threaded environment). If your service is using collections of some sort
for data storage make sure you aren't doing anything funny by going through
"hidden" synchronized accessors to your containers.
> Note:
> - It's not possible to slice the service interface into several classes
> for multithreading, because data between more than one interface can't
> be shared (at least i do not know, how this should be done, because
> several deployed interfaces have no references to each other).
I think this depends on your web container. SOAP acts like a web
application, right? So depending on how your deployment environment handles
things like scalability/failover and how many JVMs actually run it you might
be able to use some sort of Singleton/Factory patterns. Have you considered
using session techniques for storing shared information? This is probably
the preferred way.
Forgive me if I misinterpreted what you were trying to say, these are just
the first things that popped in my head.
-jason
