Singleton pattern among many verticles

[Carlo Bertuccini]

Hi,

does it make sense the use of a Singleton pattern to have an unique instance of an object among many verticles? 

In my application I connect to Cassandra (no-sql database) using Pelops client. The Pelops class create the connection pool to the DB using the static method addPool.

If I run multiple instances each Verticle that connects to DB will create it's own pool of connection but since I'm not used to think in the "verticle way" I was wondering if it's right.

I was thinking about a Singleton and I did this ...

public enum CassandraSingleton implements Serializable {    
    INSTANCE;
    private CassandraSingleton() {
          // set db parameters;
          Pelops.addPool();
    }

    public queryCassandra() {
         // do something with DB using the pool
    }
}

From my application I did something like this ...

public class MainClass extends Verticle {

      @override
      public void start() {
            - byte[] cassandra = serialize(CassandraSingleton.Instance);
            - put serialized instance of cassandra in sharedData
            - container.deployVerticle("mypackage.MyClassUsingCassandra", 5);
      }
}


public class MyClassUsingCassandra extends Verticle {
      @override
      public void start() {
             CassandraSingleton cassandra = deserialize(serialized instance from sharedmap);
             cassandra.queryCassandra();
      }
}

Using this approach I though that I would have had just one pool among the five verticles but I can see from the log that each verticle creates its own pool (and this also sometimes raise an exception for the Pelops client). What would be the right approach to have one pool to serve all verticles? Should I create a Verticle that initialize Cassandra and use the event bus to get requests and response to the other 5 verticles?

Regards,

Carlo

[Thomas Abraham]

Hi,

I'm also facing the same issue. Did you find any solution for this problem?

[Jochen Mader]

The problem is that Verticles (in Vert.x 2) are running in separate classloaders to prevent such things :)

If you want to share instances you need to do ot explicetly using shared data.

Take a look at the documentation: http://vertx.io/core_manual_java.html#shared-data

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Jochen Mader | Lead IT Consultant

codecentric AG | Elsenheimerstr. 55a | 80687 München | Deutschland
tel: +49 89 215486633 | fax: +49 89 215486699 | mobil: +49 152 51862390
www.codecentric.de | blog.codecentric.de | www.meettheexperts.de | www.more4fi.de

Sitz der Gesellschaft: Düsseldorf | HRB 63043 | Amtsgericht Düsseldorf
Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz

[Ashish Mehta]

Hi Jochen,

I am also running in simillar problem with Vert.x 3, where in I need a single instance of a class (since it caches data for me) shared across multiple verticles.

Does some workaround exist for vert.x 3 for this problem?

Regards,
Ashish

[bytor99999]

For Vert.x 2, which is what the original poster was using. I recommend next time starting up a new thread.

Vert.x 2 solution of shared data still doesn't work either because there are only certain types you can put in there, and that it is only shared in the Vert.x instance. Anyway, not the question now.

If Vert.x 3 since the classloaders were flattened, simple solution is to just store the object as a static variable in any class. That is what we did with our Spring Application Context instance.

public class AppContextHolder {
  private static ApplicationContext context

  public ApplicationContext getApplicationContext(){
    if (context == null) {

      context = new ClasspathXmlApplicationContext("locationOfConfigFile")

    }

    return context
  }
}

 

Mark

[Patryk Orwat]

In vert.x 3 you can use HK2 service factory: https://github.com/englishtown/vertx-hk2