Im am currently having issues with injection of EJBs in a thread. WildFly, Websphere Liberty >17 and even WebSphere Traditional >9 can deal with injection of EJBs in Threads, but in WebSphere Traditional 8.5 I am experiencing a NullPointerException in ResourceInjectionServiceImpl.
The JavaEE Specification says that there should be no Threads started in Beans, but not that there should be no injection in "manually created Threads". InjectionTarget is used to inject the EJBs and the created instances (after injection) are passed to an ExecutorService instance.
My question: Is there a way to get this also working in Websphere Traditional 8.5?
No, there is no way to do injection into manually created threads, mainly because you should not being doing that, as stated repetedly in the Java EE specification. You definitely should not be creating threads with EJBs, you're almost assured to have memory leaks, lock up your database pools, locking the transaction managers, among many other very common bugs.
Fortunately, if you need concurrency, you have a lot of options. The simplest is to use the #Asnycronous annotation. A robust solution is to use JMS and go fully asynchronous. Another option is to inject a ManagedExecutorService and submit tasks to it. Finally, very poor mans concurrency can be had with the Java EE Timer API.
All of these are fully supported and will not cause issues when used properly. However, creating threads is not supported in Java EE and forcing it to work will only create headaches for you later.
You may want to use ManagedExecutorService which can be obtained through the resource injection. It gives you the capability to execute your tasks in server managed thread pool. Therefore, beans created in service threads can be used in worker threads and vice-versa.
#Resource //(lookup="java:comp/DefaultManagedExecutorService")
ManagedExecutorService managedExecutorService;
Related
I have an Azure fabric cluster with .NET core 2.2 micro services inside of it. The mentioned services use EF core for communicating with Azure SQL databases. Also, the fabric cluster is behind a load balancer.
The database context has a scoped lifetime and is injected into the controllers using dependency injection.
Everything works well when the services are queried consistently by the same client, since the load balancer guarantees that for at least 4 minutes the same user will be sent to the same service instance. However, when the load balancer decides to send the user to a different instance, the database context is created again (since the lifetime is scoped, it means that a context is created per new web request). Unfortunately, the model building process takes quite long and due to that reason the first query is always way slower than the subsequent ones (on the same web request).
The questions would be, is it possible to somehow cache the EF Core model, so that it wouldn't have to be rebuilt every time the situation described above occurs ?
I mean, a similar procedure to EF - where an .edmx file is created once and loaded on context creation.
As of 3/3/2020 https://github.com/dotnet/efcore/issues/1906 this is still not possible.
If you need model caching for performance reasons you will need to use EF 6. The good news is that EF 6.3 and the the SQL Server provider for EF 6 were ported over to run on .net core 3.0. However other providers may or may not port their code over so support may be spotty.
https://devblogs.microsoft.com/dotnet/announcing-ef-core-3-0-and-ef-6-3-general-availability/#what-s-new-in-ef-6-3
I have been reading lately about safe publication of Java objects (e.g. here: http://shipilev.net/blog/2014/safe-public-construction/).
Until now I was trusting EJB container without questions when relying on container managed concurrency.
Now I'm wondering
1) how an EJB container can make sure that the EJB itself is published safely?
2) how an EJB container can make sure that objects created by its EJBs are published safely (e.g. EJB instance vars)?
E.g. stateless session bean can be accessed by different threads over time (I'm not necesseraly saying simultaneously), so unsafe publication is a potential issue.
For 1), I roughly see possibilities, e.g. by wrapping the EJB and using some volatile accesses to garantuee total order.
For 2), I don't see how EJB container can enforce it.
Maybe it is forbidden by the EJB 3.1 spec to keep instance variables in the EJB if it can be accessed by different threads?
Maybe the statement "don't worry about concurrency in container managed EJB" is not true, and I should use safe publication patterns (including volatile and/or final keywords) in the class definitions of the classes used in my EJB instance vars?
I'm surpirsed I missed this fundamental problemacy for that many years as a Java developer.
Regards,
Lars
If an EJB container is reusing instances, it must store them in a thread-safe object pool, which must use some synchronization (synchronized, compare-and-swap, etc.), which will ensure that everything written by the first thread will "happen-before" everything that happens on the second thread. EJB developers do not need to worry about synchronization (unless they're using singleton session beans with bean-managed concurrency or the EJB is going outside the scope of the EJB spec by storing data in static variables).
I'm writing a service that will call REST service every x seconds. I could do that with EJB #Schedule annotation as well as with ScheduledExecutorService.
which one is better to use? and why?
If you're writing an EJB application, you should use Schedule - the EJB spec demands that EJBs should not use threads directly, and says that doing so may cause errors in the container, as well as preventing the container from managing resources efficiently.
In exchange, with Schedule you get the benefits of container management and EJB services.
I know from experience that injection of circular dependencies in EJB do work, at least in some application servers.
I've done it multiple times with self-injection (e.g. to get an EJB proxy for #TransactionAttribute, #RolesAllowed, #Asynchronous etc. to work).
I've done it with more complex graphs too (A->B->A etc.), which obviously work too.
I've done it at least in Glassfish 3/4, Weblogic, and JBoss 7.3. Maybe Weblogic, not sure.
Now, I've been trying to find some precise guarantee from the specification, without success. There are provisions for this in CDI, but I couldn't find any explanation on why it works for EJBs. Is there some indirect one, maybe?
I'm looking from some references from EJB specifications regarding this.
I don't believe the EJB specification explicitly disallows self-injection, which means it implicitly allows it since there is no reason for the bean's own interface to be different from the interface of some other EJB. In practice, self-injection can only work for stateless (and singleton in EJB 3.1) and not stateful since each lookup/injection of a stateful bean creates a new instance, which would result in infinite recusion. For stateful, you can inject SessionContext and use the getter methods to return a "self-proxy" rather than using injection. This technique also works for stateless/singleton, and it might be marginally faster than using injection (particularly if you cache the result in an instance field the same as injection) since the EJB container can probably return a self-proxy more directly than going through injection/JNDI.
The only additional authority I can give to this answer is that I was one of the primary developers/maintainers of the EJB container in WebSphere Application Server for 5 years. To add to your list of products, I know that self-injection also works in practice on WebSphere Application Server.
We are using ejb 2.1 to expose as a webservice using apache axis2.I have read in codebranch website that both are serverside components where in ejb can be run in more than one server unlike servlets..but I didn't get clear picture of difference.
Let me quote this old (but good) comparison.
Enterprise JavaBeans are components meant to encapsulate business logic. They do not handle presentation and have a precise set of restrictions they must obey. An EJB may not manage threads, access files with the java.io package, have a GUI, accept socket connections, or load native libraries. These restrictions are imposed because EJBs execute inside an EJB container, roughly analogous to the way servlets execute in a servlet container. Where servlets can be used to perform many arbitrary tasks, including the generation of HTML pages, EJBs are used almost entirely as business objects. A session bean represents a client for a session or transaction and an entity bean represents a persistent business object that is usually stored in a database. Unlike servlets, a single session bean may exist per client. A single servlet may serve many clients. A session bean usually mediates client access to entity beans, shielding the client from the details of managing state.
I got exact answer Both are server side entities.EJB is designed by wrapping RMI API's.EJB is a service at Enterprise level.Main advantage that EJB can be a webservice which can deployed anywhere in the world.EJB is servicelayer enity which can even used by servlets.
We can have plain java in the service layer but differance that EJB has is it(EJB) can be alone deployed in any server unlike plain-java service layer.