On 17 Jul 2010, at 03:12, Praveen Sripati <praveensrip...@gmail.com> wrote:
> Thanks for the reply. > > 1. The primary advantage of the cloud is scalability. We can increase > servers from 1 to 100 within minutes based on the load. So, initially the > JDBC URL might have 1 IP and it should be updated to have 100 IPs. So, the > JDBC URL has to updated dynamically with the number of MySQL instances. Not > sure if Azure provides a resolvable name, even if it does the JDBC URL has > to be updated dynamically to reflect all the names of the new MySQL > instances. You are missing the point. Stop fixating on the db URL, you will not be able to dynamically update it, you will not be able to dynamically recreate a DBCP datasource. Even if you could this would be a really BAD strategy as it would mean each Tomcat would have to pause and wait for all requests to stop processing before each db pool is refreshed. The pool refresh operation could take a whole minute, if your clients are on a slow network connection. The Tomcat instance would be unavailable for the whole period. You would need to write your own DataSource factory to do such a thing, which I wouldn't recommend. Have you load tested your app, how do you know that your proposed strategy will solve your problem? Do you not need more Tomcat instances too? p > > On Fri, Jul 16, 2010 at 10:19 PM, Pid <p...@pidster.com> wrote: > >> On 16 Jul 2010, at 15:56, Praveen Sripati <praveensrip...@gmail.com> >> wrote: >> >>> We are in the process of migrating Tomcat and MySQL to Microsoft Azure >> Cloud >>> and facing challenges due to the dynamic nature of the cloud like >> allocation >>> of dynamic ip and ports to the instances of Tomcat & MySQL in Azure. >> Because >>> of this behavior Tomcat needs to >>> >>> 1) Dynamically update the ip and ports of the different MySQL instances >> in >>> the JDBC URL ( >>> >> http://dev.mysql.com/doc/refman/5.5/en/connector-j-reference-replication-connection.html >> ). >>> Suppose the following is the JDBC URL, then it has to be updated in >> Tomcat >>> at run-time when a new instance of MySQL is bought up or an instance of >>> MySQL is bought down. >> >> So don't put the IP address in there, put a resolvable name instead and >> dynamically update that - which is a more conventional way of doing things. >> >>> url=jdbc:mysql:replication://127.0.0.1:5104,127.0.0.1:5108, >> 127.0.0.1:5112, >>> 127.0.0.1:5116,127.0.0.1:5116/itops >>> >>> 2) We are using DBCP (http://commons.apache.org/dbcp/) for connection >>> pooling. Similarly when a new instance of MySQL is bought up or an >> instance >>> of MySQL is bought down the pool has to be updated dynamically >> accordingly >>> at run-time. >> >> While apps are using the pool? Good luck with that. >> >> You'd be better off pooling the DB and having something work out where to >> route the db pool connections and just point DBCP at that. >> >> >> p >> >>> Has anyone come across a solution for these problems while deploying >> Tomcat >>> and MySQL in Cloud? >>> >>> Thanks, >>> Praveen >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > > > -- > Praveen --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
