I'm using JBoss 7.1.1 and I have to pass an argument between two session beans.
Is it possible to pass arguments by reference from a local stateful session bean to a local stateless one?
Thanks!
That's how it works between local client and local client view. It is not only possible, but it is the way how it's specified to work. I do not try to rephrase in details, because this is quite nicely written in EJB 3.1 specification:
Session beans may have local clients. A local client is a client that
is collocated in the same JVM with the session bean that provides the
local client view and which may be tightly coupled to the bean. A
local client of a session bean may be another enterprise bean or a web
component.
...
The arguments and results of the methods of the local client view are
passed “by reference”[1]. Enterprise beans that provide a local client
view should therefore be coded to assume that the state of any Java
object that is passed as an argument or result is potentially shared
by caller and callee.
[1] More literally, references are passed by value in the JVM: an
argument variable of primitive type holds a value of that primitive
type; an argument variable of a reference type hold a reference to the
object.
Related
Could please Give RealTime Example when we should use AddSingleTon and when AddScoped and When should use AddTransient.
As far as I know, the Singleton is normally used for a global single instance. For example, you will have an image store service you could have a service to load images from a given location and keeps them in memory for future use.
A scoped lifetime indicates that services are created once per client request. Normally we will use this for sql connection. It means it will create and dispose the sql connection per request.
A transient lifetime services are created each time they're requested from the service container. For example, during one request you use httpclient service to call other web api request multiple times, but the web api endpoint is different. At that time you will register the httpclient service as transient. That means each time when you call the httpclient service it will create a new httpclient to send the request not used the same one .
Transient — Services are created each time they are requested. It gets a new instance of the injected object, on each request of this object. For each time you inject this object is injected in the class, it will create a new instance.
Scoped — Services are created on each request (once per request). This is most recommended for WEB applications. So for example, if during a request you use the same dependency injection, in many places, you will use the same instance of that object, it will make reference to the same memory allocation.
Singleton — Services are created once for the lifetime of the application. It uses the same instance for the whole application.
One of my service methods returns an non-primitive object of my own class.
The service is cluster-singleton, so I expect it to be used mostly through it's proxy on different nodes.
What will this method return? Will it be a proxy of my object too? Or will it attempt to serialize it on remote and deserialize it on a local machine?
The trick is that the object returned contains a reference to the service itself.
If serialize/deserialize happens, I expect Ignite to replace this reference with a service proxy during deserialization on a local machine. Will it happen?
Otherwise I expect it to make a proxy out of the returned object, though it is a little bit worse scenario due to subsequent bigger network interactions while working with this object.
The worst scenario would be that the service proxy can't return anything except primitives or standards.
Digging into the source code and the docs, I failed to locate my answer, please advise. What will happen:
deserialize/replace internal refs;
proxyfy;
fail;
Other?
will happen - your custom object will be serialized and sent across the network.
What happens to your service, I'm not entirely sure. Maybe it will be also serialized and sent across network :) of course, in this case it will become a different instance.
Now, if you had your object refer to service proxy instead of the service itself (raw object outside of Ignite), the result may be different.
I am using the NamedScoped Ninject extension in an attempt to create object graphs that are constructed everytime a command handler is constructed by the container. In other words, I want a fresh object graph for every command that might get processed by its corresponding handler.
I have used the .DefinesNamedScope("TopLevelOrhcestrator") binding when registering my "command handlers" as they are the top level for command processing.
A type in this named scope needs to be injected with the result of a method call on a type already registered in this named scope. I thought the best way to do this would be with a ninject provider.
Inside the provider I attempt to resolve the type in hopes I can call a method on it to pass into another object I am creating within this named scope. The problem I'm having is that when I ask the IContext for the instance inside the customer provider I get an exception that says "No matching scopes are available, and the type is declared InNamedScope(TopLevelOrchestrator).
context.Kernel.Get<TypeAlreadyRegisteredInScope>().MethodThatGetsAnotherDependency()
Is it possible to get types from the container inside a Ninject provider when they are registered inside a named scope?
EDIT
I apologize if the use case seems a bit odd, I am experimenting with some ideas about how to manage my units of work and other services/managers that may need a handle to the uow to complete a business usecase. I know its common for the unit of work to be "started" and then passed into all dependencies that may need to take part in a larger process. I was thinking I'd rather let my orchestrator take a unit of work factory so that it could deterministically destroy the UOW and it would be clear who the owner of a usecase is. What would get supplied to the managers/services would be a proxy to the unit of work that would be null until a real unit of work was started by the orchestrator. That's why I was attempting to link the proxy from the already registered type in my provider. This is all very experimental at this point and was testing some ideas.
I'd be happy to hear any further thoughts.
For MethodThatGetsAnotherDependency() to be able to .Get<>() an instance that is bound .InNamedScope(...) you will need to add the Context Preservation Extension.
This is because NamedScope is adding a parameter to the request context of the binding that has .DefinesNamedScope(...). As soon as that request is over, that context and it's parameters are forgotten. Now with the ContextPreservation extension the context is kept and reused for late / factory creations (Func<>, interface factory with .ToFactory() binding...). It think it should also work with providers.
If not, just switch to a factory instead of a provider.
However i have to admit that i don't fully understand why/what you are trying to achieve. There might be simpler ways.
Im trying to migrate a stateful session bean from EJB 2.1 to EJB 3.0, the home interface of the bean which extends EJBHome has a create method with two args and the corresponding bean has a matching args ejbcreate method and one more no arg ejbcreate method.
My question is-
1. do I need to create two constructors one no arg and one arg to migrate this stateful session bean?
2. The ejbcreate method code is throwing "CreateException" and a run time exception, as of now ejbcreate defines throws "CreateException", do i need to define thorws CreateException" on the constructor or can I skip the create exception throwing part in the code of the constructor.
Other alternative I see posted in one blog is creating a method and annotating with #init, though not sure if this is the way as they were talking about EJB2 client view for a EJB3 bean.
There is unfortunately no way to specify arguments while creating a stateful session bean using EJB 3, so you'll need to add an initialize(arg1, arg2) method and call it after obtaining in instance via JNDI.
Only the no-arg constructor can be used in EJB 3.
Yes, #Init is the equivalent of ejbCreate when using annotations to define the EJB 2 client view when using EJB 3 style bean definition.
I am reading Juval Löwy's Programming WCF Sevices. It mentions:
In WCF, we have Context in which we have the instance. By default, the lifetime of the context is the same as that of the instance it hosts. We can have separate lifetimes for both.
WCF also allows a context to exist without an associated instance at all.
Why would we release the instance and keep the context empty?
Coincidentally I recently read the chapter you're probably referring to. In his book Löwy explains why this may be useful. First he writes:
WCF also allows a context to exist without an associated instance at all. I call this instance management technique context deactivation.
After mentioning this is typically done using an OperationBehavior with a specific ReleaseInstanceMode, he goes on and hints on when you could use this:
You typically apply instance deactivation on some but not all service methods, or with different values on different methods. [...] The reason you typically apply it sporadically is that if you were to apply it uniformly, you would end up with a per-call-like service, in which case you might as well have configured the service as per-call.
So you can use this "deactivation" to ensure only certain methods in a service with sessions behave as if they were part of a per-call service. The abovementioned MSDN article also explains this, in a different wording:
Use the ReleaseInstanceMode property to specify when WCF recycles a service object in the course of executing a method. The default behavior is to recycle a service object according to the InstanceContextMode value. Setting the ReleaseInstanceMode property changes that default behavior. In transaction scenarios, the ReleaseInstanceMode property is often used to ensure that old data associated with the service object is cleaned up prior to processing a method call.
Disconnecting the context from the instance makes sense when:
Instance creation is customized/extended. For example if you are creating your service instance with a custom IInstanceProvider with a dependency injection library (for example Unity) you might want a Unity lifetime manager to handle the service instance lifetime.
Some but not all operations result in an expensive service instance to be invalidated. For example: The service object loads a large expense resource as a part of creation. If the service operations called by the client modify or invalidate the resource, it needs to be disposed and reloaded for the next caller. If the operations don’t invalidate the resource the service instance can be reused by the next caller. (In almost all cases there’s a better way to solve this problem, but WCF allows it).
I’m sure there are additional use cases.