3 Answers
3

It may be bad style but one way is to mix imperative and functional styles by having your actor (which requires connections) to have the connection pool plugged in directly and use synchronization to get a Connection. To be honest, I don't really see what is wrong with this approach; I much prefer it to the !!or !? one, which just screams deadlock (or even livelock)!

I guess one other way would be to send a message to your pool which expressed the work which needed to be done with the connection and a possible target for the result:

I'm actually using a connection pool as a means to ask about actors and the means to access a shared resource. Are you saying that actors should not be used to access a shared resource?
–
davetron5000Oct 29 '09 at 21:28

No - I'm not saying that at all. However, multiple actors can be injected with the same connection pool and use synchronization where appropriate to get a connection. Any of the other methods you describe are also valid, but I would definitely avoid any blocking calls on actors.
–
oxbow_lakesOct 29 '09 at 22:06

I guess my question is from the "Threads and synchronization are hard/difficult/not great and that's why Scala implements Actors" school. i.e., I'm told that Scala solves concurrency with Actors. So, in this very simple case, what is the pattern? The third version is the only one that avoids blocking, but it seems kludgy to me
–
davetron5000Oct 30 '09 at 0:10

@davetron5000 - I completely agree. Note that actors do not get around the need to synchronize - the synchronization of resources (like the mailbox and the internal state of the actor) is done for you in the send and receive/react methods.
–
oxbow_lakesOct 30 '09 at 10:27

By "get around the need to synchronize" I mean "get around the need for ME to put the synchronize keyword in MY code"
–
davetron5000Oct 30 '09 at 13:10

The trouble with this is that if you have a single Persistence actor, you have introduced a bottleneck. But if you want a ConnectionProvider actor and wish to avoid blocking calls, there's no nice solution
–
oxbow_lakesOct 29 '09 at 22:08

Right, the Connections themselves are not shared resources; the pool of connections is; that is why I am using an Actor to own the pool of resources. I'm wondering how the actor model works WRT to accessing resources from the pool.
–
davetron5000Oct 30 '09 at 0:08