We currently have a JavaEE deployment using Glassfish and the JCA neo4j-connector, which means neo4j is started as an EmbeddedGraphDatabase for which we can only use neo4j community.
My boss requires me to investigate on how to add high-availability, replication, and globally all services neo4j enterprise could allow us to use. In that direction, I'm currently thinking about modifying that CJA connector to no more use an embedded neo4j instance, but rather connect to a separate process eventually running on the same machine.
There are, however, some questions on that topic.
First of all, it seems there was in earlier versions of neo4j a RemoteGraphDatabaseService. it seems to be gone. is it really ? More important, our application uses JCA to coordinate transactions using XA between the various components. How can I keep that transaction coordination to an external neo4j instance considering the REST API doesn't seems to support customizable transaction size (one REST call IS one transaction for neo4j).
I think it should be pretty easy to modify the JCA connector to use HighlyAvailableGraphDatabase instead. You just have to pass in the config that is needed for HA, backup etc.
Related
I want to access Neo4j db concurrently through a rest client in java.
I have already found two clients neo4j-rest-graphdb 2.0.1 and neo4j-jdbc 2.3.2 .
Since first one is no longer maintained I'm afraid to go with it.
Can someone please tell me what is the best java rest client for Neo4j which support concurrent access?
I think what you're looking for is Neo4j-OGM
Neo4j OGM is a fast object-graph mapping library for Neo4j, optimised for server-based installations and utilising Cypher via the transactional HTTP endpoint.
It's created and maintained by Neo4j team.
Concurrency is managed by Neo4j itself, you can use any client without worrying for concurrency problem.
Is it possible to form a cluster in which there are different types of application servers? For instance, 1 JBoss, 1 Glassfish and 1 WebSphere? Lets assume we are using EJB3.0.
Stateless session beans should be relatively easy and simple load balancing among the instances should do the work, but what about SFSBs and session replication? Is it possible to utilize some cache storage like infinispan for it?
I would appreciate any comments or sharing your experience on this topic.
I assume it may be possible if you use some application server agnostic solution like Hazelcast. According to its documentation it's pretty easy to configure web session replication and the only requirements it has are
Target application or web server should support Java 1.5+
Target application or web server should support Servlet 2.4+ spec
Session objects that needs to be clustered have to be Serializable
I've not tried to configure a cluster the way you've described, however I think it may do the trick.
The responce is simply NO. Clusturing is a non standard feature, it is up to the Java EE implementation to provide clustoring keeping standard behaviour (with very litle constrains, as stickiness is expected and session object are expected to be serializable) and no interoperability is forseen.
You can of course made the cluster your self, setting up an external data grid to serve as session store and manage your self the cache, but then you will lose any framework functionality related to the session (you will need to do every thing by your self) and what the point any more to use a full Java EE application server. Yes you will then need to forget about SFSBs.
I am ready curous what issue you want to solve by this type of architecture. I don't see any that can over come the cost of maintining 3 differents apps (app server have slite difference on the dev side) and more importantly 3 differents infrastructure operation stack (on this side there is lot of difference, so you need to multiply the opperation team knowlages).
I am working on a desktop Java application that is supposed to connect to an Oracle database via a proxy which can be a Servlet or an EJB or something else that you can suggest.
My question is that what architecture should be used?
Simple Servlets as proxy between client and database, that connects to the database and sends results back to the client.
An enterprise application with EJBs and remote interfaces to access the database
Any other options that I haven't thought of.
Thanks
Depending on how scalable you want the solution to be, you can make a choice.
EJB (3) can make a good choice but then you need a full blown app server.
You can connect directly using jdbc but that will expose url of db (expose as in every client desktop app will make a connection to the DB. you can not pool, and lose lot of flexibilities). I would not recommend going this path unless your app is really a simple one.
You can create a servlet to act as proxy but its tedious and not as scalable. You will have to write lot of code at both ends
What i would recommend is creating a REST based service that performs desired operations on the DB and consume this in your desktop app.
Start off simple. I would begin with a simple servlet/JDBC-based solution and get the system working end-to-end. From that point, consider:
do you want to make use of conenction pooling (most likely). Consider C3P0 / Apache DBCP
do you want to embrace a framework like Spring ? You can migrate to this gradually, and start with using the servlet MVC capabilities, IoC etc. and use more complex solutions as you require
Do you want to use an ORM ? Do you have complex object graphs that you're persisting/querying, and will an ORM simplify your development ?
If you do decide to take this approach, make sure your architecture is well-layered, so you can swap out (say) raw JDBC in favour of an ORM, and that your development is test-driven, such that you have sufficient test cases to confirm that your solution works whilst you're performing the above migrations.
Note that you may never finalise on a solution. As your requirements change, and your application scales, you'll likely want to swap in/out the technology most suitable for your current requirements. Consequently the architecture of your app is more important than the particular toolset that you choose.
Direct usage of JDBC through some ORM (Hibernate for example) ?
If you're developing a stand-alone application, better keep it simple. In order to use ORM or other frameworks you don't need a J2EE App Server (and all the complexity it takes with it).
If you need to exchange huge amounts of data between the DB and the application, just forget about EJBs, Servlets and Web Services, and just go with Hibernate (or directly with plain old JDBC).
A REST based Web Services solution may be good, as long as you don't have complex data, and high numbers (try to profile how long does it takes to actually unmarshal SOAP messages back and to java objects).
I have had a great deal of success with using Spring-remoting and a servlet based approach. This is a great setup for development as well, since you can easily test your code without deploying to an web container.
You start by defining a service interface to retrieve/store your data (POJO's).
Create the implementation, which can use ORM, straight JDBC or some pooling library (container provided or 3rd party). This is irrelevant to the remote deployment.
Develop your application which uses this service directly (no deployment to a server).
When you are satisfied with everything, wrap your implementation in a war and deploy with the Spring DispatcherServlet. If you use maven, it can be done via the war plugin
Configure the desktop to use the service via Spring remoting.
I have found the ability to easily develop the code by running the service as part of the application to be a huge advantage over developing/debugging something running on a server. I have used this approach both with and without an EJB, although the EJB was still accessed via the servlet in our particular case. Only service to service calls used the EJB directly (also using Spring remoting).
I have the following scenario:
I have an interface-server which listens on a queue and receives messages from the "outside world". This server then calls a "internal", business, service which in turn calls other services and so on.
These services can each reside on a different machine, and can be clustered for that matter.
I need the notion of a transaction to span across these services and machines.
My development stack includes Spring (3.0.5) and JPA 2.0(Hibernate in background) on a J2SE environment.
Can I acheive this without an app-server? Assuming I plug-in an external JTA transaction-manager (like atomikos for example)
We've chosen to go with Spring for many reasons the most important ones were the service abstractions, intensive DI and the ability to work without a heavy app-server. I know we can use spring in an app-server but if someone is to recommend this I'd like to hear why this should be done, assuming I can forefit spring and go all app-server.
BTW, just to reassure anyone reading this post: Yes, we've thought of the problematic issues of a distributed transaction but we still think we will need such a transaction as this is the business logic of the service and it will need to be across machine as some of the services will be under a lot of pressure.
Thanks in advance,
Ittai
We ended up using JBoss with Spring.
JBoss indeed supplied the distributed transactions that were needed while Spring contained all DI and such.
We still kept spring as we felt its IOC was cleaner and more comfortable.
It is possible we should have used CDI in jboss but that was not on our radar.
We use Spring 3 and Atomikos for distributed transactions (xa) on apache tomcat and oracle databases in production, so this for us a very usefull setup. Have a look at the atomicos spring integration example:
http://www.atomikos.com/Documentation/SpringIntegration
Is it safe to run a database connection pool (like Commons DBCP or c3p0) as part of an application deployed to an application server like Glassfish or Websphere? Are there any additional steps over a standalone application that should be taken to ensure safety or performance?
Update, clarification of reason - the use case I have in mind could need new data sources to be defined at runtime by skilled end users - changing the data sources is part of the application's functionality, if you like. I don't think I can create abnd use container-managed pools on the fly?
AFAIK it works, but it will of course escape the app. server management features.
Also, I'm not entirely sure how undeployment or redeployment happens and whether the connections are correctly disposed. But that can be considered as a minor safety detail: if disposed improperly, connections will simply time out I guess. I'm also not entirely sure whether it works for XA data source which integrates with the distributed transaction manager.
That said, using the app. server pool is usually a matter of configuring the JNDI name in a configuration file. Then you get monitoring, configuration from the admin console, load management, etc. for free.
In fact, you can create container-managed datasources depending on AS you use.
For example, Weblogic has an extensive management API that is used, for example, by their own WLST (Weblogic Shell) to configure servers by scripts. This is, of course, Java API. It has methods to create and configure datasources too.
Another route is JMX-based configuration. All modern AS expose themselves as JMX containers. You can create datasources via JMX too.
All you need is to grant your application admin privileges (i.e. provide with username/password).
The benefit of container-managed DS is it can be clustered. Also, it can be managed by human being using standard AS UI.
If that doesn't work for you, why, sure you can create application-managed DS any time and in any numbers. Just keep in mind that it will be bound to a specific managed server (unless you implement a manual clustering of it's definition).
I don't see why you'd want to. Why not use the connection pool that the app server provides for you?
Update: I don't believe it's possible to create new pools on the fly without having to bounce the app server, but I could be wrong. If that's correct, I don't believe that Commons DBCP or C3P0 will help.