We Keep Coding

CouchBase Client vs Spymemcache, Client Usage

I am to use CouchBase as my caching layer. My caches are serialized objects and not(always) Document type or JSON values. The couchbase client(Couchbase-Java-Client-1.4.3) also uses Spymemcache jars which is the client of memcached server.
My questions are,
Should I use only Couchbas Client to cache my objects into couchbase server?
What if I use default Spymemcache client to cache ? if I use, what could be pros and conse over the using couchbase client? Can the Spymemcache client handle server nodes and node failures itself?

You should not use Spymemcached with Couchbase. You can, but I would recommend against it. First off, CouchbaseClient uses the Spymemcached jar because both Memcached and Couchbase use the memcached binary protocol for key-value operations. When we initially started writing a Java Client for Couchbase it didn't make sense to re-implement something that was already written so we used Spymemcached because it performs very well. You can think of Spymemcached as doing all of the basic stuff like sending messages and Couchbase Client as adding all of the nice functionality that makes it really easy to use Couchbase.
What if I use default Spymemcache client to cache ?
Everything goes through the cache regardless of what client you use so there is not point in using two different clients.
What could be pros and cons over the using couchbase client?
If you don't use CouchbaseClient you will be using something a lot more primitive. Think about it this way. Couchbase has spent about 3 years adding features to CouchbaseClient that make it really easy to use the Couchbase. CouchbaseClient will deal with topology changes and also adds operations that Spymemcached does not have.
Can the Spymemcache client handle server nodes and node failures itself?
No, but if you send traffic through Moxi then you will be able to deal with node failures.
I wouldn't even both with Spymemcached if your using Couchbase.

Can Hazelcast be used as a cache for *perl* web apps?

I am looking at quickly implementing a hazelcast in-memory cache for a web application.
The web application is written in perl...
...so is there a way to access a hazelcast Map via perl?
Or, in worst case, must I write a thin hazelcast client in java, and call that from perl?
Thanks
Steve

I'd suggest looking at Cache::Memcached as this post to the hazelnut google groups seems to imply that someone else has already done this using this module.
For other solutions, you could continue searching on cpan for Memcache. Or for a non distributed solution, can just go with the core library Memoize.

If there a memcached client for Perl? If so you can use the memcached protocol to connect to Hazelcast.
Chris

Hazelcast could be used through its REST Api so you need a JVM with Java library to support this feature.

How to connect to a remote neo4j instance using a GraphDatabaseService?

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.

Using Couchbase with memcached protocol from Java

Can someone point me to example of Java code that can work both with Memcached server and Couchbase server. If i understand correctly one can use spymemcached for communicating with both server. Does that mean i can use same code to connect(obviously using different url) get and put values to them or there are some differences?

Any particular reason to use the memcached protocol directly?
The best practice when working with Couchbase is to use the Client SDK (many languages are supported as you can see here http://www.couchbase.com/develop , including Java) ?
The reason why it is better to use the SDK (and for the same reason you have to use Moxi) is because to be able to support the clustering from your application.
You client SDK will direct the operations to the correct cluster nodes, but also the cluster map will automatically be updated when you add new nodes (or when nodes are failing).
The Java SDK tutorial will guide you through the different steps of developing an application using Couchbase:
- http://www.couchbase.com/docs/couchbase-sdk-java-1.1/tutorial.html
So, can you use the Java client SDK?

According to the couchbase documentation it support textual memcached protocol. So you can use any of the available java memcached client and reuse the same code used for memcached. Couchbase supports memcached protocol only through moxi.

Oracle/Java application, recommended architectures

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).