Difference between MongoDB and RDBMS

Why RDBMS (SQL):

  • Frequent CRUD transactions for a limited similar type of data in GBs.
  • It’s good for structured data.
  • This kind of database is tightly structured with schema and perform slower (low latency) with huge growing data.
  • RDBMS performs faster for low amount of data ( in GBs).
  • SQL DBs- Oracle, MySQL, SQLServer etc.

Why MongoDB (No-SQL):

  • Write once and read many for unstructured data.
  • It’s faster than RDBMS for growing data on clusters/cloud in TB, PB etc.
  • If there is a requirement to not update DB frequently (not mission critical), dissimilar data , then go for this.
  • No SQL DBs- MongoDB, Cassandra, NeoJ, CouchDB, Hadoop, Cloudera, MapR etc.

In nutshell, if you have simple data without any complex relationship then why to choose complex RDBMS. Both are not replacement of each other, both have their own importance. I think it will be helpful to understand use cases of these two databases.

How to decide usage of Java Collections ???

ArrayList – orderd, fast iteration and fast random access.
LinkedList – orderd,fast insertion and deletion
HashSet – unsorted, unordered Set. no duplicates and you don’t care about order.
LinkedHashSet– orderd, Use this class instead of HashSet when you care about the iteration order.
TreeSet– Sorted.
HashMap– unsorted, unordered. don’t care about the order.
LinkedHashMap– maintains insertion order (or, optionally, access order). slower than HashMap for adding and removing elements, you can expect faster iteration with a LinkedHashMap.
TreeMap – Sorted. TreeMap lets you pass your own comparison rules in when you construct

5 scenarios where you can bet for EJB3

I have most of the times worked on spring based projects. Recently I got a chance to design business layer based on EJB 3.

Below are the observations based on my experience.Any architect may consider EJB 3 , for these aspects.

  1. JMS Consumers: When you need to develop JMS consumers: EJB supported MDB are simplest JMS consumers having annotated transaction support.
  2. Asynchronous Communication: In EJB 3.1, session beans support asynchronous method invocations. Bean methods annotated with @Asynchronous are invoked asynchronously. When a client invokes methods with the @Asynchronous annotation, the container immediately returns control to the client and invokes the method in a different thread. The method may return a future object to allow the client to check on the status of the method invocation, and retrieve result values that are asynchronously produced. EJB 3.1 supports this feature by using Future, which is part of standard java concurrency. Future represents the result of an asynchronous computation. It supports both model of communication:,
    1. Retrieve-result-later asynchronous methods having Future<?> return type.
    2. Fire-and-forget asynchronous methods having void return type
  3. Multi node deployment
  4. Distributed Application: EJB3 support for remoting and simple distributed transaction support makes spring first choice for distributed applications.
  5. State-full Behavior

 

You can achieve all the features with other frameworks as well, but one need to develop custom components or integrate other frameworks, while these features are embedded in EJB 3 and can be applied easily.

Aspects of Web application to be secured

To ensure security of a web application is an important requirement now days.  One needs to first do a vulnerability assessment.

For example:

  1. If there is file upload feature, Application can be vulnerable for uploading viruses.
  2. If there is form submission, Application can be vulnerable for html/js injection.
  3. If plain JDBC has been used, there can be threat for sql injection.

One practice can be to setup some design and development guidelines to ensure that application is secure to at least common vulnerabilities. Please read more at http://makesecurejava.blogspot.in/

Singleton Design Pattern in a clustered Environment !!!

When to Use:

We can use Singleton pattern while creating objects of thread pools, caches etc to avoid wasting resources. If you want to store global information like item price of products etc. It’s now a anti-pattern and you should avoid it by different substitutes.

Important Note: It has now become Anti-design pattern and we should avaoid by using follwoing techniques:

1. Dependency Injection

2. Using Factory design Pattern

3. Using Enum class etc. (Introduced in Java 1.5)


// Enum singleton - the preferred approach 

public enum MySingleton{
 INSTANCE Consolas, Monaco, monospace; 
}

Singleton Design Pattern in a clustered Environment [Source: http://www.techspot.co.in/2009/07/singleton-in-cluster.html%5D


In a multiple JVM’s environment, each of them will have their own copy of the singleton object which can lead to multiple issues specially in a clustered environment where the access to the resource needs to be restricted and synchronized.

To achieve clustering across multiple JVM’s, one can use multiple techniques (JMS, DB, Custom API, 3rd party tools), but each of them have an impact on the business logic.

  • Application server’s also provide some level of custom API’s to circumvent this problem.
  •  Terracotta, Oracle Coherence are good options. These work on the concept of providing an in memory replication of objects across JVMs in effect providing you singleton view  or making use of any of the cluster-aware cache provider’s like Swarm Cache or JBoss TreeCache should work as cache entries are singletons and clustering is built in.
  • Also, there is product called JGroups – which uses mulch-cast communication (TCP/UDP).  It allows to form a group and Applications (JVM’s) can participate and JGroups will send messages to everyone in the group so that they can be in sync.
  • JBoss has has Singleton Service ( based on MBeans) which is meant to solve this problem. Check here and here
  • Weblogic has the concept of Singleton Service – where only instance runs within the cluster and all clients will look up to the same instance.
  • WebSphere supports the concept of singleton across cluster in the WebSphere XD version of the application server as the partition facility – ObjectGrid