-
30. Re: Conversation regarding JBoss MC and Nuts container betwe
"ajoo" wrote:
Even for a non DataSource thing, when we re-deploy a service, how do we know the object is not already obtained and kept as reference by a client? We have no way to tell the client to "re-obtain me" in such case.
Things like a DataSource are just thread safe factories.
They point at configuration that says "this how you get a connection".
e.g. for a DataSource there is a pool of preconstructed db connections.
The server can easily throw away the pool and start again without affecting the factory.
It doesn't even require a restart of the DataSource, see flush():
http://wiki.jboss.org/wiki/Wiki.jsp?page=HowDoIChangeThePoolingParameters -
31. Re: Conversation regarding JBoss MC and Nuts container betwe
"ajoo" wrote:
Let's say a client is designed as:class BankAccount{ private A a; void f(){ this. a = jboss_container.get("service A"); } }
Suppose the system is already running, and at a certain time in the past the "BankAccount.f()" executed. That caused "BankAccount" as a client of jboss container, obtained an instance of A from the container and kept it locally for future use.
If we now choose to re-deploy "service A", how do we know that BankAccount keeps a local reference of the old A? I suppose we have no way to know that.
But if we do not know, "BankAccount" will still hold a reference to the old A even after a new A is deployed. And that is not desirable.
Yes, but in middleware the client does not a have a true java reference to the
back account.
It either has a disconnected pojo that represents the state "the last time it looked"
or it has a proxy with an id that helps it re-retrieve the state on the next invocation.
If you want to enforce correctness you use a transaction across the different
invocations. What I have been calling "in flight" requests. -
32. Re: Conversation regarding JBoss MC and Nuts container betwe
I'm sorry. I meant that "BankAccount" is _the_ client. It is holding a reference to something it "last time looked".
-
33. Re: Conversation regarding JBoss MC and Nuts container betwe
"adrian@jboss.org" wrote:
If you want to enforce correctness you use a transaction across the different
invocations. What I have been calling "in flight" requests.
And of course once you have transaction, the client has a retryable unit of work.
The server has the option to fail the transaction, giving the client the guarantee
that nothing bad happened. It can just start the transaction again with the new service.
For "transactional pojo state" see this:
http://docs.jboss.org/jbcache/current/TreeCacheAop/html/
Section 2.
"Transaction. The POJO operation can be transacted once a TransactionManager is specified properly. Upon user rollback, it will rollback all POJO operations as well."
Assuming you are even using such potentially bad (or at least lazy) patterns
as updating client state with information from an incomplete transaction. ;-) -
34. Re: Conversation regarding JBoss MC and Nuts container betwe
Anyway, we've gone a bit off-topic discussing the proper construction
of applications using transaction assembly to protect against complete or partial
failure.
But you can see how JBoss is solving different problems to a simple IOC container ;-) -
35. Re: Conversation regarding JBoss MC and Nuts container betwe
"adrian@jboss.org" wrote:
But you can see how JBoss is solving different problems to a simple IOC container ;-)
Or at least you understand why knowing a bit more than one thing uses another
is important in the JBoss Microcontainer ;-) -
36. Re: Conversation regarding JBoss MC and Nuts container betwe
"adrian@jboss.org" wrote:
"ajoo" wrote:
Let's say a client is designed as:class BankAccount{ private A a; void f(){ this. a = jboss_container.get("service A"); } }
Suppose the system is already running, and at a certain time in the past the "BankAccount.f()" executed. That caused "BankAccount" as a client of jboss container, obtained an instance of A from the container and kept it locally for future use.
If we now choose to re-deploy "service A", how do we know that BankAccount keeps a local reference of the old A? I suppose we have no way to know that.
But if we do not know, "BankAccount" will still hold a reference to the old A even after a new A is deployed. And that is not desirable.
Yes, but in middleware the client does not a have a true java reference to the
back account.
It either has a disconnected pojo that represents the state "the last time it looked"
or it has a proxy with an id that helps it re-retrieve the state on the next invocation.
If you want to enforce correctness you use a transaction across the different
invocations. What I have been calling "in flight" requests.
Excuse me, Adrian. I'm not sure I understand your explanation, the same as I'm not sure if you are answering my question. :-)
What I meant is more at "semantics" level. How are we sure that "re-deployment" of a service is transparent to the clients?
In the "BankAccount" example, when "service A" is re-deployed (class reloaded), how do we know to re-configure "BankAccount.a" field?
I'm sorry I can't see what Transactional Caching can do here. -
37. Re: Conversation regarding JBoss MC and Nuts container betwe
"ajoo" wrote:
Excuse me, Adrian. I'm not sure I understand your explanation, the same as I'm not sure if you are answering my question. :-)
What I meant is more at "semantics" level. How are we sure that "re-deployment" of a service is transparent to the clients?
You cannot "know" unless the services are written "properly" such that the MC "knows".
In this example you aren't even using IOC and if it really matters in this case
(e.g. it is not a stateless threadsafe factory), you shouldn't be usinglocator.getDirectReference()
semantics.
This is what I said before about scripting semantics.
If the container doesn't understand what you are doing it can't help you
in anything except providing a reference.
After that, you are on your own. -
38. Re: Conversation regarding JBoss MC and Nuts container betwe
Adrian, if I'm not mistaken again this time, you are saying that client code should be designed "properly". Code following bad practices is not mc's concern. They don't work then they don't work.
Is that the rationale? -
39. Re: Conversation regarding JBoss MC and Nuts container betwe
"ajoo" wrote:
Adrian, if I'm not mistaken again this time, you are saying that client code should be designed "properly". Code following bad practices is not mc's concern. They don't work then they don't work.
Is that the rationale?
Sort of the reverse. If you want to manage it yourself using a script/procedure then go ahead.
If you want the additional features, then make the necessary "declarations" to the container.
You can't say (like in your example), "it does not work" when you have sidestepped the IOC
with a locator pattern. :-)
Many frameworks, require you use framework specific API.
My aim is to simply provide the enhanced behaviour as declarations to a state machine,
either directly or using "decorators" that provide the link between the enhanced behaviour
and the object's state/transitions.
If you just want to use JBossMC as an IOC container, then the decorators are optional.
If you just want to use it for the locator pattern, then it is that as well.
But don't expect any of the more advanced features to work consistently.
(Unless you know what you are doing. :-)