> > If we make the following assumptions:
> >
> > type 1 interface (no transaction): client may assume the component is
> > threadsafe
> >
> > type 2 or 2 interface (transaction involved): client may *not* assume
> > the component is threadsafe.
>
> Actually, even with my previous correction, my argument fails unless the
> second assumption is changed to allow the client to assume the component
> is threadsafe outside the transaction -- as this is getting less and less
> desirable, I think I might drop it, apologies for the wasted bandwidth :)
what I said here is wrong (and doesn't make complete sense)... my argument
did work (with the first correction) --- it seems that my postings are
starting to become a good approximation to thinking-out-loud.
When I wrote this I was a little confused by the following example - which
shows that the definition of transaction I was using was flawed (I'll try
to fix this in my next email)...
consider the interface:
interface Command
{
/** Contract: this method only gets called once */
public void execute();
}
which could be implemented as:
class CommandComponent implements Command // and lifecycle interfaces
{
private Type2Interface m_type2;
public void compose( ComponentManager cm )
{
m_type2 = (TypeTwoInterface) cm.lookup( "TypeTwoInterface" );
}
public void execute()
{
m_type2.begin();
m_type2.foo();
m_type2.bar();
m_type2.end();
}
}
My confusion came about because I was thinking of the Command interface as
being type 1. But it isn't, it is really type 2 with the execute() method
marking the begining *and* end of the transaction -- hence I need to
revise my definition of transaction... see next email...
Robert.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
