I need to implement a simple DAO bean, which also caches data read from the database. This DAO bean is used by stateless beans.
Because EJB3.0 doesn't support singleton beans, what would be the correct way to implement such a DAO bean? Is it ok to just use static variable to keep the cache?
We are using Oracle AS and not going to use clustering.
The "correct" way to do this in a somewhat cross-appserver way is to use a jmx mbean for the caching behavior. mbeans are singletons (per-app server) and can do things like threading and locking. depending on the appserver you use, of course, mbeans can be more or less difficult to work with in practice.
Most Application servers and JPA implementations offer some sort of built-in caching mechanism which is controllable by the user. It might be worthwhile investigating ways of accomplishing what you want without having to build a singleton.
One of the major issues with singletons and J2EE is that there is no easy way to handle them in a clustered environment.
That all said, I did find an article which makes some suggestions for possibly doing what you want under JBoss, and mentions a new #Singleton annotation for EJB3.1 so that may be a possibility. If that works for you, you should write up what you did as another answer to this question.
If you are running on Weblogic server, it is actually possible to implement a singleton bean that is also cluster-aware. I don't believe this feature exists on other application servers though.
Related
I'm currently working on a desktop Java client-server application that uses Hibernate to access a database. Many of the calls to the database are generic CRUD operations and so I'd love a way to reduce the amount of boilerplate code.
I've stumbled upon the JpaRepository/CrudRepository interfaces in the Spring Framework and would like to be able to use either of them but it feels as though I'm constantly fighting against Spring's web-application focus. For instance, as repositories are autowired in by Spring, I'm not able to instantiate a copy or make a static instance and so it becomes difficult to call any of the repository's methods from the server class.
As such I have four questions:
Is there a way to use the Spring Jpa/CrudRepository interfaces
without autowiring them in?
Is there a way to use either interface without using Spring?
Is there an alternative interface for desktop applications which would achieve the same purpose?
Is there a better alternative that I'm missing?
chrylis gave you the answer that you really need in the comments:
Make your "program" a Spring component
I'd say the appropriate way to do that would be to make it a CommandLineRunner
I'd even go beyond that and say: Even if you start you in a single process you should maintain a web like architecture, possibly even a web server in the application in order to
a) work with JPA in a reasonable way, i.e. have clearly defined requests that get processed by the server process in separate threads
b) do not block the UI while queries get processed.
To answer your literal questions:
Is there a way to use the Spring Jpa/CrudRepository interfaces without autowiring them in?
Yes, you can manually create repositories using the JpaRepositoryFactory
Is there a way to use either interface without using Spring?
The interfaces themselves are just interfaces and can be used without anything else from Spring.
Of course the benefit of that is limited.
Is there an alternative interface for desktop applications which would achieve the same purpose?
No, there is no need for that.
Is there a better alternative that I'm missing.
I don't think so but I'm biased.
Given I have deployed 2 ears on my WildFly instance. I want to setup some communication between them. The way which seems the most comfortable for me is to use some common bean.
By 'bean' I dont mean ejb-bean because I dont use ejb. Thats an important point. Best option for me is a Spring bean.
Anyway, Spring bean, or just some instance of a some Java class, I would like to have a shared instance of some Java object in a memory of both ears, deployed on my WildFly.
Is it possible?
If not, what are the options?
Declare a queue in the standalone(-full).xml, two topics for bidirectional communication and have the ears submit and process each other messages.
This is generally not something I would recommend as it tightly couples applications. My general recommendation would be to use some sort of remoting between the applications.
Having that said there are a couple of ways to achieve this. First you have to make sure that both EARs use the same shared classes. The easiest way to do that is to move them to a JBoss module and declare a dependency in your EARs. It is important that the classes are not in the EARs. Then you somehow have to register the objects, JNDI and JMX are obvious candidates.
EJB calls should also be possible but the same rules for shared classes apply (add an interface to the EJB, share the interface between the EARs, refer to the EJB only by interface). There are various ways to make EJBs available to Spring, the obvious one being a factory bean.
Just curious,What is the use of below imports in java.I'm wrongly imported while doing hibernate stuff and those are not compatible with hibernate.
import javax.management.Query;
import javax.management.QueryExp;
I gone through the api and found in that they can fire queries on the beans.
Can i use them on my hibernate pojo(to avoid some memory eat up)??or I understood in a wrong way ??
Any idea about them??
I gone through the api and found in that they can fire queries on the beans.
Not exactly. API Page states:
The MBean Server can be queried for MBeans that meet a particular condition, using its queryNames or queryMBeans method
So, it's not exactly about regular pojos. MBean or managed bean is one of the concepts introduced by Java Management Extensions (JMX) technology. As JMX Technology Overview states:
The Java objects that implement resources and their instrumentation are called managed beans, or MBeans. MBeans must follow the design patterns and interfaces defined in the JMX specification (JSR 3). This ensures that all MBeans provide the instrumentation of managed resources in a standardized way.
Basically MBeans are used to extend standard JVM management functionality. So, developers can integrate application-specific options to standard monitoring tools (jconsole) and, thus, simplify and standardize resource administration.
Query is just a utility class that introduce several methods used to build QueryExps. QueryExp objects are used to query MBeansServer.
Can i use them on my hibernate pojo(to avoid some memory eat up)?
Well, they aren't meant to be used that way. So, using them for such a purposes will just introduce confusion.
If you are looking for a way to query your pojos (I don't understand how does it help with memory eat up, though), check out these questions:
How do you query object collections in Java (Criteria/SQL-like)?
What is the Java equivalent for LINQ?
They are part of the JMX Framework. I don't think using them without the framework would make sense.
Haven't used EJB3, but by reading a tutorial, EJB3 looks like mostly for manipulating data in database through JPA (of course, it contains other business logic). Just curious, if no database is quired, is it still beneficial to use EJB3 or it just adds complexity to an application? Will POJO be a better choice for implementation?
Big part of EJB benefits is coming from transactions and persistence.
But even without them you may benefit from EJBs. It can give you a proven clustering and balancing model. It can give you the declarative security. It can give you MDBs which are a convenient way to listen to JMS queues/topics and timers.
All above can be done using third-party libraries, such as Spring. EJBs though are highly consistent, while to get, for instance, clustering and security you may need to combine two products, and it's not guaranteed they will work together well and won't need much glue.
EJBs are transactional, distributed components deployed on an app server that manages lifecycle, threading, and other services. Persistence is just one type of EJBs. You still might find stateless, stateful, or message EJBs useful, even if you don't want to use entity beans.
With that said, you can create POJO components that are stateful, stateless, persistent or message-driven. You don't need EJBs; something like Spring can be a good alternative.
I have understood that if I use EJB in Spring context, I get all the same benefits as if I was using it in "pure" EJB3 environment, is this true? I have googled but can't find a definitive, clear answer.
For example, let's say I have a session bean that updates some tables in the database and it throws a System Exception. In "pure" EJB3 environment the transaction is rolled back. What if I for example #Autowire this bean using Spring, does Spring take care of the transaction handling same way as does the EJB3 container? Or what? Does it maybe require some specific configuration or is it fully "automatic"?
I have understood that if I use EJB in
Spring context, I get all the same
benefits as if I was using it in
"pure" EJB3 environment, is this true?
You usually use either POJO + Spring or EJB3. I'm a bit confused by what you mean by "EJB in Spring"...
POJO + Spring and EJB3 are quite close now, and have the same facilities when it comes to declarative transaction management.
I don't know all the details about security, but I would say that both technologies are also very similar.
Actually both Spring and EJB3 rely on other specifications. The important ones are: JPA (persistence), JTA (distributed transaction), JMS (messaging), JDBC (data sources). Good support for that exist in the two technology stacks.
Both technologies have become very flexible and you can choose what to use or not. So you can have EJB3 in an app. server and be very light. Or you can use Spring with all modules which is almost as heavy as a full-fledged app. server.
I think the EJB3 model is still a bit richer, with things like remoting, stateful session beans (SFSB), container-managed transactions, and extended persistence context. Plus the possible support of clustering depending on the app. server. But these are advanced features which are use seldom (and IMO require expertise).
See EJB3 vs Spring
spring has many features, one of which is transaction management, which uses a common abstraction accross all different orm implementations (jpa, raw hibernate, jdbc, jdo etc). The default behavior is that in a transactional method, a runtime exception causes a rollback (which is probably what you want), but you can also fine-tune the rollback rules.
However, none of this requires EJB. If you don't use EJBs (stateless, stateful, mdbs), JPA will be enough for that, and the spring jpa support is excellent. In 90% of the cases spring will provide everything you need without EJBs.
EDIT:
read this about Spring EJB integration
You can have Spring handle transactions and roll back accordingly. You have to configure it to do so, but that's also true of EJBs.
Nothing in life is truly "automatic". You have to tell the code what you want sometime.
The real question is: Why do you think you need both EJBs and Spring? Anything you can do with EJBs can be done using POJOs with Spring. What are EJBs buying you here?
I got very good answers with links to articles, and from those I compiled my understanding that yes, the session beans work the same way regardless of if they are used with Spring or without, as long as the beans are defined in the Spring context with <jee:jndi-lookup>. Also found a good, simple article about this: http://java.dzone.com/articles/ejb-30-and-spring-25
However I can't accept just one answer because to me they are all equally good, but none of them exactly in point :) Could be that my question was not clear enough to start with...
(It was suggested that I post this as an answer to my own question)