How can I turn off mandatory transactions in Neo4j 2.0? I need to do this as the library I am using does not support the 2.0 transactional API yet.
As you've said, in Neo4j 2.0 transactions are mandatory and there is no way to switch this off. If you're relying on Cypher be aware that the Cypher's ExecutionEngine automatically opens and closes a transaction if there is no one available from outside.
Depending on your environment and architecture you can use cross-cutting concerns to manage transactions separately from your code base. Think of java servlet filters, and aspect with aspectj, byte code manipulation, Groovy MOP magic, and other technologies. For a more focussed answer you should give more insight in your project regarding used languages, frameworks and architecture.
what if you are running neo4j in read-only mode? and you are more interested in speed rather than concurency as there is no race conditions.
from http://neo4j.com/docs/stable/transactions-isolation.html there will always be a transaction :/
Related
I know that you can write extensions that you can call from Cypher, but I'd really like to avoid having to write Java. I'm thinking something similar to SQL Server stored procedures. Is this possible, or could I maybe write a Cypher query and wrap it in some minimal Java to make the current capabilities work?
Besides #InverseFalcon's answer, there is really no Transact-SQL or PL/SQL-like languages for graphs yet.
The closest language I am aware of is SAP's GraphScriph:
GraphScript is a domain-specific, read-only graph query language tailored to serve advanced graph analysis tasks and to ease the specification of custom, complex graph algorithms.
Caveats: it is only available in the SAP HANA Graph product, and, as the quote says, it is read-only. For more details, see presentation slides and paper.
If you would like to avoid Java due to its verbosity but are fine with writing general purpose code on the JVM, you might want to try the Kotlin language. However, using anything else than Java tends to introduce some integration issues (across all JVM-based applications, not just Neo4j in particular), so be prepared to tackle those. There is an example project on GitHub for Neo4j Kotlin procedures to get you started. Caveats: even though there is basic Kotlin support in the Eclipse IDE, it's not on par with the IntelliJ edition. So you will probably need an IntelliJ license.
If you have access to APOC Procedures, you can use apoc.cypher.run() (or apoc.cypher.doIt() for write-queries) to execute a string cypher query.
You can always follow the tutorial for creating your own procedure and have it call the appropriate APOC cypher run procedure with a hardcoded query.
Is there any tool for viewing registered types in CORBA Trading Service, and maybe, for making some simple queries for objects?
I am using TAO, if it matters.
Not that I know off. Maybe you can write your own and contribute it back to TAO. Maybe consider a scripting language for a client, like Ruby with the R2CORBA implementation which is interoperable with TAO
EJB achieved many improvements in 3.x versions, Spring is also commonly used and version 3 is a good alternative.
There are many articles on web, but no exact comparison about ejb3x versus spring3x.. Do you have any ideas about them, in real world examples which one is better at which conditions?
For example, we want to separate db and server, which means our application will be on a server, our database will be in another server.. EJB remoting vs Cluster4Spring etc ?
Doing everyting #Annotation is always good? configuration never needed?
For your use case where the application runs on one server and the database runs on another, the choice between EJB and Spring is irrelevant. Every platforms supports this, be it a Java SE application, a simple Servlet container like Tomcat or Jetty, PHP, Ruby on Rails, or whatever.
You don't need any kind of explicit remoting for that. You just define a datasource, provide the URL where your DB server lives and that's it.
That said, both EJB and Spring Beans do make it easier to work with datasources. They both help you defining a datasource, injecting it in beans and managing transactions associated with them.
Of the two, EJB (and Java EE in general) is more lightweight and adheres more to the convention over configuration principle. Spring requires more verbosity to get the same things and depends a lot on XML files which can quickly become very big and unwieldy. The flip side of the coin is that Spring can be less magical and you might feel more in control after having everything you want spelled out.
Another issue is the way EJB and Spring are developed.
EJB is free (as in free beer), open-source and non-proprietary. There are implementations of EJB being made by non profit organizations (Apache), open source companies (Redhat/JBoss) and deeply commercial closed source enterprises (IBM). I personally would avoid the latter, but to each his own.
Spring on the other hand is free and open-source, but strongly proprietary. There is only one company making Spring and that's Springsource. If you don't agree with Rod, then tough luck for you. This is not necessarily a bad thing, but a difference you might want to be aware of.
Doing everyting #Annotation is always good? configuration never needed?
It's an endless debate really. Some argue that XML is hard to maintain, others argue that annotations pollute an otherwise pure POJO model.
I think that annotating a bean as being an EJB stateless bean (#Stateless) or a JPA entity (#Entity) is more cleanly done using annotations. Same goes for the #EJB or #Inject dependency injections. On the other hand, I prefer JPQL named queries to be in XML files instead of annotations, and injections that represent pure configuration data (like a max value for something) to be in XML as well.
In Java EE, every annotation can also be specified in XML. If both the annotation and the XML equivalent are present, the XML overrules the annotation. This makes it really convenient to start with an annotation for the default case, but override it later via XML for a specific use case.
The current preference in Java EE seems to be more towards (simple) annotations combined with a large amount of convention over configuration.
The real question you should be asking is CDI/EJB or Spring
It's often not Spring vs EJB, but Spring vs Java EE. EJB itself compares to Spring Beans. Both of them are a kind of managed beans running inside a container (the EJB container resp. Spring container).
Overall the two technologies are rather similar. Reza Rahman did a great comparison between the two a while back.
EJB's are more advantageous because of standardization. If you are working with a lightweight application I think going with Spring is fine but if you expect that your application will be big and will require lots of memory access and data connections access you may consider starting your development with EJBs. The main reason being clustering and load balancing are built into the EJB framework.
In an EJB environment, when an EAR ('E'nterprise 'AR'chive) is deployed, it may be deployed with multiple EJBs beans that each could have a specific purpose. Let say you wrote a bean for user management and another bean for product management. Maybe one day you find that your user services way exceed your products access services, and you want to move your user bean to a different server on a different machine. This can actually be done in runtime without altering your code. Beans can be moved between servers and databases, to accomodate clustering and load/data balancing without affecting your developers or your users because most of it can be configured at the deployment level.
Another reason for supporting a standard is knowing that most large third party vendors will likely support it resulting in less issues when integrating with new standard/service/technology - and let's face it, those come out like new flavours of ice-cream. And if it is in a public specification new start-up companies or kind developers can create an open-source version.
http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html
It is most unfortunate that even the most intelligent designers or programmers cannot predict which of their features may or may not be embraced by the development community which is the main reason software becomes bloated... Java EE is definitely that!
Choose one or the other, but not both.
My personal preference is Spring. I've used on projects with great success for the past six years. It's as solid as any software out there.
Spring can work with EJBs if you choose to have them in your app, but I don't believe the reverse is true.
I would recommend separate physical machines for web, app, and database servers if you can afford it.
Spring can work with several remoting options, including SOAP and REST web services. A comparison of Spring beans with EJB is beyond the scope of this question. I don't see what it has to do with your implementation. If you use Spring POJO services they're in-memory rather than requiring another network hop like remote EJBs. Think of Fowler's Law of Distributed Objects: "Don't". Only introduce latency with good reason.
I'd mention unit testing here.
In common web application (controller->service->data->...->view) EJB and Spring both provide similar result, but spring offers easier testing.
In my humble experience the way you develop is different in couple of aspects:
Unit test (spring wins). In spring its done pretty stright forward, while in ejb you have to use Arqullian with ShrinkWrap (sic!) which is slow to run on every build.
Persistence (ejb wins). In spring there is struggle around it, i.e. google "how to autowire persistence in entity listener" http://bit.ly/1P6u5WO
Configuration (ejb wins). As newbie coming to spring from ejb I was surprised by swarm of annotations and .xml files.
EJB 3.1 is the best while being the standard for Java 6 EE applications.
Spring still does not support Java 6 CDI(weld) also still depends a lot on XML configuration. EJB 3.1 is powerful and smart.
I think that Spring 3.1 doesn't need any XML configuration. You have the option to use annotations for configuration.
So I've been tasked at work to write windows services to replace some old legacy VB6 WinForms apps currently running as services, consistently repeating tasks day-to-day. To give some general background, they have there own state machines built in to handle decision basing and not utilizing threading.
A lot of the senior developers here thought it would be worth a try to look into WorkFlow to replace the state machines rather than write my own business logic and try threading it programmaticly. So it's WF vs. the "Old College Try" I suppose.
My concern is that there aren't many books on the topic, and since it was implemented in .Net I've heard very little about it being used. I brought this up at work and another developer mentioned that it's because Biz Talk never really caught on and it was designed for that.
So is it broken? Do you think it will be supported long enough to not worry so much? I don't want an ill-functioning process injected into my services, my new babies at work, and then have WF's keel over. Leaving me with having to replace them with my own code in the event of an emergency; which does not seem like much of a grand scenario to me.
Any suggestions, recommendations would be super.
Workflow Foundation is used in Microsoft SharePoint, so I think they will continue supporting it.
There is an open source project called Stateless by Nicholas Blumhardt. It is quite flexible and very light weight. See my SO answer for details.
I chose this over Windows Workflow simply because I could define a state as State and thereby persist the state of my workflows back to the database using SubSonic. Configuration consists of one XML file. If I need to add tasks, I simply add nodes to the XML.
The each state can have a series of triggers that once satisfied will advance to appropriate state. This framework is a single assemble and fits nicely in your domain logic.
Suppose I want to implement an application container. Not a full-on Java EE stack, but I need to provide access to JDBC resources and transactions to third party code that will be deployed in an application I'm writing.
Suppose, further, that I'm looking at JBossTS for transactions. I'm not settled on it, but it seems to be the best fit for what I need to do, as far as I can tell.
How do I integrate support for providing connection resources and JTA transactions into my Java SE application?
How do I integrate support for
providing connection resources and JTA
transactions into my J2SE application?
Hi Chris
There are two elements to this problem:
1) Making the JTA API, mainly UserTransaction, available to application code, so it can start and end transactions. In A Java EE environment it’s published into a well known location in JNDI. If you have a JNDI implementation that’s the way to go (Use JBossTS’ JNDIManager class to help you with the setup). Otherwise, you need some kind of factory object or injection mechanism. Of course you can also expose the implementation class direct to the end user, but that’s somewhat nasty as it limits any chance of swapping out the JTA in the future.
public javax.transaction.UserTransaction getUserTransaction() {
return new com.arjuna.ats.internal.jta.transaction.UserTransactionImple();
}
That’s it – you can now begin, commit and rollback transactions. Some containers also publish the TransactionManager class to applications in similar fashion, but it’s really designed for use by the container itself and rarely needed by the application code.
2) Managing enlistment of XAResources automatically. Resource managers i.e. databases and message queues, have drivers that implement XAResource. Each time the application gets a connection to the resource manager, a corresponding XAResource needs to be handed off to the JTA implementation so it can drive the resource manager as part of the 2PC. Most app servers come with a JCA that handles this automatically. In environments without one, you need some alternative to save the application code from having to do this tedious task by hand. The TransactionalDriver bundled with JBossTS handles this for JDBC connections. XAPool may also be worth considering.
JBossTS has been embedded in many environments over the years. Some of the lessons learned are documented in the Integration Guide http://anonsvn.jboss.org/repos/labs/labs/jbosstm/trunk/atsintegration/docs/ ] and if you want a worked example you could look at the tomcat integration work http://anonsvn.jboss.org/repos/labs/labs/jbosstm/workspace/jhalliday/tomcat-integration/ ]
JBoss's TM is horrible. At least, if
you are hoping for ACID transactions.
Hi erickson
I don’t think I’d go quite as far as ‘horrible’. It’s incredibly powerful and highly configurable, which can make the out of box experience a bit daunting for newcomers. Correct recovery configuration is particularly tricky, so I fully endorse your comment about rigorous testing. Beyond that I’m not aware of any documented test cases in which it currently fails to provide ACID outcomes when used with spec compliant resource managers. If you have such as case, or just more constructive suggestions for improvement, please let JBoss know so the issue can be addressed.
Don't reinvent the wheel. Use the
Spring Framework. It already provides
this functionality and much more.
-1 Spring does not provide a JTA implementation, just a wrapper for various 3rd party ones. This is a common misunderstanding.
JTA supports local transactions and
global transactions.
Another misconception I’m afraid. The JTA spec deals only with XA i.e. global transactions. Various well known techniques exist for making a JTA transaction manager drive local transactions. These usually involve wrapping the Connection in an XAResource. Whilst most implementations support this it’s actually outside the scope of the spec and so you must check with the vendor before choosing a JTA implementation if you need this behaviour.
Try Atomikos TransactionsEssentials.
Unlike competing open source JTA/XA implementations, this one was written from the start for JSE. Consequently, it offers premium JDBC and JMS pools as well as JTA/XA functionality, and you will find it very easy to integrate into your applications.
Best
Guy
Don't reinvent the wheel. Use the Spring Framework. It already provides this functionality and much more.
You can use Spring, much as I'm not that keen.
An example of what you might want is here
JTA supports local transactions and global transactions.
Local transactions can be easily handled by Spring, JPA or even manual commits on connections.
Global transactions REQUIRE a transaction coordinator. That's a separate product/library which is not readily available in open source (or at least I'm not aware of it).
So, if I look onto the header of your post ("JTA"), the answer is NO SIMPLE WAY.
If I read your posting itself ("provide access to JDBC resources and transactions"), I'd say Spring, JPA and Hibernate all would cover your needs (as I understood them).
P.S. Correction: JTA doesn't really support local transactions (as people have pointed me out), but a case when you only need a single connection is essentially a local transaction, even if controlled by JTA, especially when Transaction Manager is located in the same JVM (as it often happens).
"JBoss's TM is horrible. At least, if you are hoping for ACID transactions. The best that one can say about it is that it will probably not screw up as long as it doesn't have to contend with any failures. And it's not alone... most transaction managers (even some commercial ones) really don't work."
Not sure what homework you did to make the above statement, but JBossTS (the TM in JBoss since 2006, when it was acquired) does provide full ACID semantics. It was also originally part of the HP NetAction suite, where it was deployed in more mission critical applications than any of the other open source TMs.
I've elected to use the Bitronix Transaction Manager to solve this problem, although apparently there's at least one other option that wasn't apparent to me at the time (Atomikos).
Solving this ended up requiring me to use the Tomcat in-process JNDI provider as well, in order to associate the transaction with a JNDI name. Due to a limitation of that provider, I could not use the default name for a JTA UserTransaction, which isn't immediately apparent from the documentation.
Thanks to all for the helpful answers anyhow!