FlexyPool 2 has been released
Introduction I’m happy to announce you that FlexyPool 2 has just been released! I started FlexyPool in 2014 because, at the time, I was working as a software architect on a large real-estate platform and we were about to launch the system into production. Because the system was split into multiple modules, we needed a way to figure out the right pool size for each module. To make matters worse, the front-end nodes could be auto-scaled, so we needed monitoring and same fallback mechanisms in case our initial assumptions did not hold… Read More
How does FlexyPool support both Connection proxies and decorators
Proxies FlexyPool monitors connection pool usage and so it needs to intercept the connection close method call. For simplicity sake, the first version was relying on dynamic proxies for this purpose: As straightforward as it may be, a proxy invocation is slower than a decorator, which calls the target method using a direct invocation. Because all connection pools use proxies anyway, adding another proxy layer only adds more call-time overhead and so now FlexyPool supports connection decorators as well.
Professional connection pool sizing with FlexyPool
Introduction I previously wrote about the benefits of connection pooling and why monitoring it is of crucial importance. This post will demonstrate how FlexyPool can assist you in finding the right size for your connection pools. Know your connection pool The first step is to know your connection pool settings. My current application uses XA transactions, therefore we use Bitronix transaction manager, which comes with its own connection pooling solution. Accord to the Bitronix connection pool documentation we need to use the following settings: minPoolSize: the initial connection pool size maxPoolSize: the… Read More
FlexyPool, reactive connection pooling
Introduction When I started working on enterprise projects we were using J2EE and the pooling data source was provided by the application server. Scaling up meant buying more powerful hardware to support the increasing request demand. The vertical scaling meant that for supporting more requests, we would have to increase the connection pool size accordingly. Horizontal scaling Our recent architectures shifted from scaling up to scaling out. So instead of having one big machine hosting all our enterprise services, we now have a distributed service network. This has numerous advantages: Each JVM… Read More