Re: MySQL component

Mark Matthews wrote:
 > Steve Loughran wrote:
 >>> Phillip Thurmond wrote:
 >>> Hello all.  I'm currently implementing a performance testing system in
 >>> smartfrog.  i was wondering if anyone has written or knew of a 
smartfrog
 >>> component to install and manage MySQL.  I've seen one mentioned in a
 >>> couple of presentations, but couldn't find the code anywhere.  All 
of my
 >>> code will be licensed LGPL, so any added features (or bugs :) ) to an
 >>> existing component will be shared.  Thanks.
 >>>
 >>> --Phillip
 >  [snip]
 >
 >> One of the fun things here is shutting down mysql cleanly. Our normal
 >> execution routines shut things down by issuing a destroy() command to
 >> the process, there being no portable way to issue kill signals to a
 >> process in Java. I worry what state this will leave the database in.
 >> I've added a component, mysqladmin-shutdown to issue a shutdown 
command,
 >> which can go into a new workflow component, Finally {}, that will run
 >> the program when it terminates
 >
 > Hi Steve,
 >
 > First, I'm replying to this on -developer, because the -user mailing list
 > seems to have disappeared.

Hi Mark. We normally find the smartfrog-support mail list is where the 
users hang out, because its where they look for help, from us and from 
other users.

 >
 > From the dates on the SVN repo, I see that you're still actively 
working on
 > this component (and I'm actually looking at using SmartFrog internally at
 > MySQL AB for some of our system testing).

Yes, I am busy with the components. I have just checked in the first 
pass at the documentation last Friday, which needs a reread, a fuller 
example and a roadmap.

In this first release I've focused on the simple use case of "bring up 
the database to go with the application server", using HSQLDB as the 
simple example, MySQL as the full fledged one, and targeting Unix 
variants as the single host to focus on. While I have everything working 
to the extent it passes its test cases when run on Linux, it is still 
limited. After the next SmartFrog release, I'd expect to add

- the ability to get the results from SELECT operations into attributes, 
so that you can do LAZY bindings to the results of DB operations.

-RMI methods on the components to remotely issue transactions through a 
deployed transaction

-caching of connection details from the DatabaseBinding, so that those 
components that run at shutdown don't depend on the DatabaseBinding 
still being live.

-Possibly, pooling in the DatabaseBinding component. I'm unsure about 
this as I'm not sure how much load you should be generating during 
deployment, and to support pooling means that we'd need to deploy a new 
DatabaseBinding in every process. I may make it an optional extra; a 
DatabaseConnectionPool component that implements the relevant binding 
attributes/RMI interface, but also offers a non-exported pool API for 
stuff in the same JVM to use.

-Better windows support.


 >
 > I'm wondering if you've happened to look at Connector/MXJ which wraps 
up a
 > mysqld and gives you configuration and lifecycle methods either as a 
POJO or
 > an MBean? It might make your component quite a bit more straightforward:
 >
 > http://dev.mysql.com/downloads/connector/mxj/1.1.html
 >
 > Let me know what you think, and I can hook you up with the developer who
 > maintains it.
 >

This looks really interesting, and anything that makes it easier to 
start/configure/stop MySQL is very welcome. We have a JMX component that 
can introspect and invoke JMX classes, though pre-Java 1.5, there's some 
issues with building and distributing it. As Java 1.5 ships with a 
working JMX implementation out the box, life gets a lot easier.

At the same time, we want to keep the core of the SmartFrog components 
LGPL, on the basis that the tools for deploying your system shouldn't 
dictate the license you use. Right now we don't have any real 
dependencies on MySQL except for the tests, and even though the MySQL 
FLOSS License Exception should let us stay LGPL, we like to make it 
clear to downstream users that any run time deployment of your JARs 
means that the GPL T&Cs apply.

If we can stay under the FLOSS exception, then adding explicit support 
for the JMX drivers is something we can easily do after the next 
SmartFrog release (when we will switch to Java 5 across the board). 
Otherwise, we will have to create a specific sourceforge project for GPL 
licensed components, which just adds more complexity to our build process.

-Steve


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV