Hi Hans, Thanks for the suggestions, but unluckily it has to be done that way as for my Oracle dba instructions. Coding some function for preventing the user from executing another query could be a nice solution, I'll do some test. I'm trying some solution based on getting the database session as soon as I get the connection item and then killing the db session if needed. It's risky, I know, but I'll let you know if it works.
Thanks again Enrico Drusiani -----Original Message----- From: Hans [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 08, 2004 02:45 PM To: Tomcat Users List; 'Freddy Villalba Arias'; 'Tomcat Users List' Subject: RE: JNDI Datasource advanced use Hi, seems to me you are talking about 2 different things: - preventing the user from executing a huge query while another is running - cancelling the huge query The first can easily be implemented using some flags in a user session, the second I don't know ;-). What does your database documentation has to say about threadsafety and such? I can imagine running a worker thread for the long query, and the main thread closing the connection, but I do not know if this really cancels the running query. Look here for example to see how you can handle this in mysql: http://dev.mysql.com/doc/mysql/en/KILL.html Instead of closing a connection, you would have to determine the proces id for your query and kill it, at least that is what I gather from this page. grtz Hans ps on a side note, running huge queries on a frequent basis by lot's of users isn't cool. Do they have to modify the data as well? Is it possible to preprocesses the data into a smaller table? At 14:33 08/06/2004 +0200, Enrico Drusiani wrote: >Hi Freddy, > >Thanks for your fast reply. Actually with closing i mean bolcking the >execution of the Statement.executeQuery(String SQL) method (or the >like) while it is running. For being more accurate and in order to give >you an idea of the data flow, that query can actually work on some million records. >As you can guess, it may mean to wait for a couple of minutes before >having a resultset to show to the user back on the browser. And user >don't like to wait that long. A typical user, even if long waiting time >for huge queries are specified in the manual, don't actually read the >manual. So they hit the back button, thinking the system was blocked >and redo the query that gets some minute to finish... so they hit the >back button and on again. That's why I'd like to give the user a nice >"cancel" button and get rid of all those huge queries going on in the background. > >Thanks again > > >Enrico Drusiani > > >-----Original Message----- >From: Freddy Villalba Arias [mailto:[EMAIL PROTECTED] >Sent: Tuesday, June 08, 2004 01:48 PM >To: Tomcat Users List; Edrusiani >Subject: RE: JNDI Datasource advanced use > >Hi Enrico, > >I suppose that by "closing" you mean freeing up the resource. When you >close a connection that has been obtained from a DataSource, I believe >it is not actually closed, but only released, hence made available to other processes. > >How many connections are there, for how long, and that sort of things... >they should be transparently managed by the underlying product (the one >where you configured your DS). > >If this resembles your scenario, then closing connection should do it; >obviously, you will still have to handle the consequences of "closing" >a >connection: rollback (or not) any transaction, etc... etc... > >HTH, >Freddy. > >-----Mensaje original----- >De: Enrico Drusiani [mailto:[EMAIL PROTECTED] >Enviado el: martes, 08 de junio de 2004 13:14 >Para: [EMAIL PROTECTED] >Asunto: JNDI Datasource advanced use > >Greetings everyone. > >I need to give the user of my servlet based web application the chance >to close a connection to a db if it takes too much time (some of my >queries work on a huge amount of data). I was thinking of something like a "cancel" >button that asks a servlet to close the working connection. Can that be >achieved by using the JNDI datasource or have I to use some more >advanced data layer like hibernate or jdo? > >Thanks for your time and attention > > >Enrico Drusiani > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > >Tracking #: 0C05932399AE9D43B10CEBB8E94D2ADF007EE8D9 > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
