Re: SyncronizingProxyFactory: Pattern or antipattern?
On Mar 25, 2:41 am, "Chris Uppal" <chris.up...@metagnostic.REMOVE-
THIS.org> wrote:
Daniel Pitts wrote:
I thought that it might be annoying to write stuff like:
synchronized(target) { target.doOp(); target.doOp2(); }
over and over again. So I thought to borrow a concept from Aspect
Oriented Programming, and wrote myself a proxy factory.
I worry a little when concepts like automatic synchronising wrappers turn up.
The problem is that the appropriate granularity of synchronisation depends on
the meaning of the operations invoked by the API, and by their interrelations,
rather than by the boundaries between the actual methods in the API.
If the API is unusually well-defined, then each semantic operation will
correspond to exactly one method call (which is a valuable property for an API
in itself, and even more so when API calls involve moving data over a
network[*]). But if not -- as is typical -- then automatically adding
"synchronize" to each method call will not provide the necessary safety.
In your example:
synchronized(target) { target.doOp(); target.doOp2(); }
would be implemented by the automatic wrapper as if the code said:
synchronized(target) { target.doOp(); }
synchronized(target) { target.doOp2(); }
which doesn't provide the same semantic guarantees at all.
The converse of the same point is that the locking behaviour of an application
is not something that can be fully encapsulated and hidden away. It is an
issue that can have global ramifications for the design of an application,
unless you want to risk poor performance or even deadlocks. In non threaded
code you can (putting things in OO terms) just ask some object to do something,
and let it worry about the implementation -- so the large-scale application
architecture is not dependent on the details of how the object implements that
operation -- but that is doesn't always apply where locks are concerned, since
any held lock can potentially lock out any other piece of code. That's not
always a problem, but where it is, I'd worry that low-level, automated
facilities would not be "intelligent" enough to do the job properly.
The greatest danger (IMO) is that the code which uses the wrapper /may/ be
correctly designed to use synchronisation properly, or it may not, and there is
no way to tell which just by reading it. I.e. there is no way to tell
easily -- or even make a good guess -- whether the implicit synchronisation is
any of:
+ correct by carefully considered design
+ correct by unconsidered default
+ correct but unnecessarily slow
+ incorrect
That worry is greater still when there may be more than one proxy for the same
object. In normal circumstances, multiple proxies are either a complete no-no
(which may apply in your case, though you don't mention it); or are considered
to be a normal state of affairs. If your semantic safeness depends on the
proxies all agreeing on how they synchronise, then you may have to put more
work into that part of the design than you've shown so far (presumably the
separation of the 'target' and 'sync' objects in the wrapper API is intended to
be a step in that direction).
All of those are good points.
A little more background for my particular project might help.
I have a class "Game", which contains at least one member of type
"GameState". GameState is an abstract class, implementing the "State/
Strategy" pattern. Certain method calls are only valid with certain
states. The actual value of the GameState object depends on the valid
operations on Game.
So, here comes the synchronizing design...
Operations on Game need to be atomic, and Game is already large enough
that I'd prefer not to delegate to GameState within game. I created a
facade class "GameController" which references a "Game" object. There
can be several GameController objects per Game object. GameController
delegates to a few methods in Game, and then all methods in
game.getGameState(). I am asserting that each method on
GameController needs to be atomic to the given Game object. Hence the
target/sync in my proxy.
My target would the GameController, and my sync would be the Game.
This allows the GameController to behave correctly even if there are
more than one acting on the same Game.
I realized that my code would have to be constructed with the concept
that the method call itself was the atomic operation, not a group of
them. This is knowledge that is important anyway, so if someone
doesn't understand this, then they are likely to write incorrect code
with and without my proxy, I think.
To put it another way. my GameController only exposes methods which
are transactional. It is also only invoked by a user performing an
action in a GUI. The operations themselves are fast enough, and
spread far enough apart, that the synchronization isn't going to harm
performance, and is actually required for proper operation.
On Mar 25, 2:41 am, "Chris Uppal" <chris.up...@metagnostic.REMOVE-
THIS.org> wrote:
The only case I can think of (so far) where the automatic synchronised wrappers
might be worthwhile is if the wrapper is /only/ intended to protect the state
of the network proxy object itself, not the state of the object it is a proxy
/for/. (In which case method-level boundaries would be appropriate -- but then
I'd sort of hope the RMI implementation would have that under control anyway).
Actually, I think you've got this backwards...
The GameController would be proxied to a threadSafeGame. The
threadSafeGame object stays on the server side, and then a
gameControllerRemoteStub is sent to the Client side... The Stub is
actually a proxy for the threadSafeGame, and the threadSafeGame a
proxy for the gameController. Calls on the client side may be serial,
but they might be parallel as well. the threadSafeGame makes them all
serial with regards to the game object.
Does this design make more sense? Or do you still think its an
antipattern?