How to deal with lock in Vertx

[Michael Pog]

I am building a web service with Vert.x. I create multiple instances of a verticle that has an http server.

The server handles get, put and post requests. 

The idea is to have a map between keys and values, where a get would retrieve and fetch the value,

and a put would update the value. For that of course a hashmap would be the best.

However that means that I will have to have a hashmap that is shared by verticle threads. The first thing that comes to mind is a ConcurrentHashMap  https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ConcurrentHashMap.html 

However I believe it (and many other concurrent data structures) have internal locking inside. 

From reading about how to work properly with vert.x, it says not to use any locks, mutexes etc.

How could I keep my service, scalable, simple and fast in that case?

Thanks

[ad...@cs.miami.edu]

Is this going to be in the same JVM?  If so, I don't see why a concurent hash map would not work.  You will need to have mechanism such that each verticle has a reference to the same hashmap instance.

As I understand it, a synchonized class like ConcurrentHashMap could be used, but realize that a synchonized object can block the event loop in a verticle.   But a ConcurrentHashMap doesn't typically block too long.  I think it will be fine.

As I understand it, you can use synchonized object in vert.x, but you just need to follow the standard java rules of synchronization, while in standard vert.x approach everything is single threaded.

-Adam

[Jez P]

Don't forget vert.x also has a Shared Data implementation. Maybe that would help you.

[Tim Fox]

Yep, SharedData maps were designed pretty much for this purpose.

[Michael Pog]

I am not using it in a cluster, just in one application, with multiple verticle instances, that need to read and write from/to the same hashmap.

Is the Shared Data preferred over a concurrentHashMap in terms of performance?

Is very planning to provide nonblocking/lock free collections in the future?

[Julien Viet]

Hi,

> On May 5, 2017, at 4:41 PM, Michael Pog <smic...@gmail.com> wrote:
>
> I am not using it in a cluster, just in one application, with multiple verticle instances, that need to read and write from/to the same hashmap.
>
> Is the Shared Data preferred over a concurrentHashMap in terms of performance?

the shared data is actually a ConcurrentHashMap , the difference is that it copies key/values when necessary (like Buffer or JsonObject which are mutable) making sure that it is safe for you to use between different verticles.

if you store your own objects, they should implement the Shareable interface, Shareable objects are supposed immutable.

>
> Is very planning to provide nonblocking/lock free collections in the future?

I don’t think we plan to provide lock free collection classes, you can simply reuse existing ones.

>
> --
> 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.
> Visit this group at https://groups.google.com/group/vertx.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/27fc158f-4bc1-45e0-9c62-1eaba6be9cb9%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[ad...@cs.miami.edu]

the shared data is actually a ConcurrentHashMap , the difference is that it copies key/values when necessary (like Buffer or JsonObject which are mutable) making sure that it is safe for you to use between different verticles.

If everything is in the same JVM (as OP suggested), why would copies of key/values need to be made?  Can't verticles just share a reference to the same concurrent hashmap and not worry about a structure that copies keys/values among different verticles.  A singleton wrapper around a hashmap should allow the concurrent hashmap to be easily shared safely... unless I am missing something?
 

[Julien Viet]

on reason is to ensure that there are no visibility issues when you use these objects between different threads and mutate them.

if the overhead is an issue, you should just use an concurrent hashmap

On May 6, 2017, at 8:45 AM, ad...@cs.miami.edu wrote:

the shared data is actually a ConcurrentHashMap , the difference is that it copies key/values when necessary (like Buffer or JsonObject which are mutable) making sure that it is safe for you to use between different verticles.

If everything is in the same JVM (as OP suggested), why would copies of key/values need to be made?  Can't verticles just share a reference to the same concurrent hashmap and not worry about a structure that copies keys/values among different verticles.  A singleton wrapper around a hashmap should allow the concurrent hashmap to be easily shared safely... unless I am missing something?
 

--
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.
Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5af73884-a01e-4a49-a976-ef136074ea46%40googlegroups.com.