Hi Thomas, The JMX approach is architecturally elegant and has certain advantages. But using the existing DatabaseEventListener is lightweight and requires less code to be added to H2. It is nicer to use the existing approach (DatabaseEventListener) rather than add a duplicate effort (JMX).
So if you are happy with me adding new states to DatabaseEventListener, I'll do so. That was my first trial approach actually! The DatabaseEventListener notifications run on the database server thread. A consequence is that an API user might inadvertently write code that causes delays to the query. So I propose also making the calls to DatabaseEventListener.setProgress run using a dedicated Executor. For backwards compatibility maybe this should be optional though. What do you think? Shall I make the notifications asynchronous? Regards Steve On Monday, 12 March 2012 09:06:03 UTC+1, Thomas Mueller wrote: > > Hi, > > It sounds like JMX would be used as a "event mechanism". Until today I > didn't know that this was even possible... > > I understand extending the DatabaseEventListener might be a backward > compatibility issue. But what about adding new states in > the DatabaseEventListener? For example: > > DatabaseEventListener.STATE_STATEMENT_START > DatabaseEventListener.STATE_STATEMENT_END > > Existing listeners should still work, and wouldn't have to be changed. > Maybe they throw an exception for a (so far) unknown state, but such > exceptions could be ignored. Therefore, it wouldn't be a interface > compatibility problem, just a semantical compatibility problem. Because > throwing exceptions is slow (the fillInStackTrace part), that would mean > reduced performance, but I think that's OK. > > What do you think? > > Regards, > Thomas > > > > > On Sat, Mar 10, 2012 at 6:23 PM, Steve McLeod <[email protected]> > wrote: > > Hi Thomas and others, > > > > I've patched the current H2 source to extend the usage of JMX. If JMX > > is enabled for a database, then it sends a notification whenever a > > query starts and whenever a query ends. > > > > Is this something you'd consider adding to the H2 trunk? If so, I'll > > finalise my patch and submit it. > > > > Currently it is a proof of concept but I envisage adding notifications > > for all DML and DDL commands. > > > > My use case is tracking long running schema manipulation queries such > > as "ALTER TABLE ADD COLUMN", which actually performs several commands, > > including "CREATE TABLE", "DROP TABLE", "CREATE INDEX". Currently > > these can't be tracked in their entirety to give users helpful > > feedback. I also envisage this being a way to eventually track long- > > running SELECT queries, by sending a notification after every x rows > > are handled. > > > > Alternatively I could modify the existing DatabaseEventListener to do > > this, but as that would require changing an existing API, I think this > > would not be a good approach. > > > > Regards, > > > > Steve > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "H2 Database" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > [email protected]. > > For more options, visit this group at > http://groups.google.com/group/h2-database?hl=en. > > > > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To view this discussion on the web visit https://groups.google.com/d/msg/h2-database/-/IIwfBmsHSXsJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
