views:

75

answers:

1

I'm working on a JVM project which uses ESRI components (COM based, wrapped with JIntegra.) The client has requested the JAR files we produce work on the JVM and be accessible to Java code. I'd like to use Scala but I'm worried about how well the library will play with Scala's actors. Particularly I'm worried about the different mechanisms COM and Java employ to pass objects from one thread to another.

Does anyone have any experience with this? Will they play nice?

Edit: for clarification

I noticed that when performing I/O on the ESRI DB that the CPU utilization is roughly 15%. I'd like to read each row and pass that row over to another actor for parsing. Then I could have several threads reading from the DB at once. The problem is that each row retrieved using ESRI's library is actually a Java wrapped COM object.

+1  A: 

Actors may not be the right paradigm for you then. Ideally messages between actors will be immutable, and only an actor's internal state will be modified. It sounds like you want to supply a row to an actor, then have the actor modify the row in-place.

If so, you'll still have all the same concurrency risks as using threads+locks, which is possibly a better solution for this particular problem.

On the other hand, if the rows ARE immutable, and the actors return something that is derived from the rows (without having altered them) then it should "just work", and I wouldn't be especially concerned about different ways in which Java and COM see threads.

Kevin Wright
If you say not to worry about different threading mechanism issues, then I yield to your experience. The rows are mutable but I'm not mutating them. And to the why of Actors vrs. the standard consumer-producer, let's just say that there's a lot of people here at work who don't understand basic threading issues but could grok message passing.
wheaties