Using MySQL in project and am pretty much repeating this code for every query: spec := (JdmConnectionSpec new initialize
user: 'root'; password: '...' host: (NetNameResolver addressForName: '...' database: '...'
port: ...). connection := JdmConnection on: spec. statement := connection createStatement.
sql := 'SELECT * FROM ... WHERE ...'. resultSet := statement executeQuery: sql. ...
connection close. If I try to construct a different SQL statement and execute "resultSet := statement executeQuery: sql." without first executing a "connection close." then repeating:
connection := JdmConnection on: spec. statement := connection createStatement.
sql := 'SELECT * FROM ... WHERE ...'. resultSet := statement executeQuery: sql.
it fails. Am I missing something? ---John |
Hi John,
JC> it fails. Am I missing something? no you do it exactly right as you use the native mysql driver which is - quite old - gpl which may or may not be a problem - only works if you -open a connection -fire a query -get the result -close the connection!! -repeat ad infinitum. Take a look at SqueakDBX which (according to their Benchmarks) is faster and blocks the image much less. I use the native driver in a commercial in house app for years but I tested SqueakDBX http://www.squeakdbx.org/ enough to be sure it does the same work without the drawbacks. Now only someone has to pay me to rewrite quite an amount of software which is working well to use the better driver :-)) Cheers, Herbert mailto:[hidden email] |
2010/1/11 Herbert König <[hidden email]>:
> Hi John, > > > JC> it fails. Am I missing something? > > no you do it exactly right as you use the native mysql driver which is > - quite old > - gpl which may or may not be a problem > - only works if you > -open a connection -fire a query -get the result > -close the connection!! -repeat ad infinitum. > > Take a look at SqueakDBX which (according to their Benchmarks) is > faster and blocks the image much less. > > I use the native driver in a commercial in house app for years but I > tested SqueakDBX http://www.squeakdbx.org/ enough to be sure it does > the same work without the drawbacks. > > Now only someone has to pay me to rewrite quite an amount of software > which is working well to use the better driver :-)) > Or use better DB - CouchDB ;) > > Cheers, > > Herbert mailto:[hidden email] > > > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Herbert König
Herbert König wrote:
> Hi John, > > > JC> it fails. Am I missing something? > > no you do it exactly right as you use the native mysql driver which is > - quite old > - gpl which may or may not be a problem > - only works if you > -open a connection -fire a query -get the result > -close the connection!! -repeat ad infinitum. > > Take a look at SqueakDBX which (according to their Benchmarks) is > faster and blocks the image much less. Another alternative is ODBC (http://www.squeaksource.com/ODBC.html). It works very well for us in production. Cheers, - Andreas |
In reply to this post by John Chludzinski
Took your all’s advice and switched to the ODBC driver. Works well ! Thanks. ---John
|
El mar, 12-01-2010 a las 15:49 -0500, John Chludzinski escribió:
> Took your all’s advice and switched to the ODBC driver. Works well ! > Thanks. ---John Well, is your codebase but I would like to know why SqueakDBX isn't good enough for you. AFAICT SqueakDBX is being maintained currently. Haven't seen much about ODBC in this lists in the past 3 years. Anyway, if it fits to your project then that's is enough. Cheers -- Miguel Cobá http://miguel.leugim.com.mx |
The biggest problem I found with the ODBC driver for Squeak is that it uses FFI and it locks the complete VM during the function invocation. In ODBC, queries are synchronous, so, if you have a website with multipleusers, and someone sends a query, it is likely the complete vm will be locked until it finishes.
You can see what I am talking about in my slides: http://www.slideshare.net/esug/squeak-dbx There I compare both drivers. I am not an ODBC expert, so if someone think that that's incorrect, please let me know. Cheers Mariano 2010/1/12 Miguel Enrique Cobá Martinez <[hidden email]> El mar, 12-01-2010 a las 15:49 -0500, John Chludzinski escribió: |
Mariano Martinez Peck wrote:
> The biggest problem I found with the ODBC driver for Squeak is that it > uses FFI and it locks the complete VM during the function invocation. In > ODBC, queries are synchronous, so, if you have a website with > multipleusers, and someone sends a query, it is likely the complete vm > will be locked until it finishes. I've been wondering about that. It says here (http://wiki.squeak.org/squeak/6129): --------------------------------------- OpenDBX and FFI You can have a common problem which is that SqueakDBX, trough FFI... --------------------------------------- This implies you're using FFI to talk to OpenDBX. How's that different from ODBC? Cheers, - Andreas > > You can see what I am talking about in my slides: > http://www.slideshare.net/esug/squeak-dbx > > There I compare both drivers. I am not an ODBC expert, so if someone > think that that's incorrect, please let me know. > > Cheers > > Mariano > > 2010/1/12 Miguel Enrique Cobá Martinez <[hidden email] > <mailto:[hidden email]>> > > El mar, 12-01-2010 a las 15:49 -0500, John Chludzinski escribió: > > Took your all’s advice and switched to the ODBC driver. Works well ! > > Thanks. ---John > > Well, is your codebase but I would like to know why SqueakDBX isn't good > enough for you. AFAICT SqueakDBX is being maintained currently. Haven't > seen much about ODBC in this lists in the past 3 years. > > Anyway, if it fits to your project then that's is enough. > > Cheers > -- > Miguel Cobá > http://miguel.leugim.com.mx > > > > > ------------------------------------------------------------------------ > > |
On Tue, Jan 12, 2010 at 11:29 PM, Andreas Raab <[hidden email]> wrote:
That's exatly what it is explained in the slides, even with sequence diagrams. OpenDBX, when possible, uses asynchronous queries. This means that it just calls a function to send the query, and then, it loops asking "is it ready?" until the query is done So, we have "little locks". The goods news is that after asking, if there are other process in the queue, it should be processed. With this way we process several queries "at the same time.". Se the method DBXPlatform >> processNextResultSet: aConnection querySettings: aQuerySettings where we do: (code = OpenDBX resultTimeout) ifTrue: [ (Delay forMilliseconds: (aQuerySettings timeout asMiliseconds)) wait ]. It is not the best solution, of course, but we are limited to FFI implementation. I said "OpenDBX, when possible" because it not depends only in OpenDBX but also in the client library. Some support this and some doesn't. But I think most engines support this. I know PostgreSQL does. BTW, which OS are you deploying on ? Mariano Cheers, |
Mariano Martinez Peck wrote:
> That's exatly what it is explained in the slides, even with sequence > diagrams. > > OpenDBX, when possible, uses asynchronous queries. This means that it > just calls a function to send the query, and then, it loops asking "is > it ready?" until the query is done So, we have "little locks". The > goods news is that after asking, if there are other process in the > queue, it should be processed. With this way we process several queries > "at the same time.". Se the method DBXPlatform >> > processNextResultSet: aConnection querySettings: aQuerySettings > > where we do: (code = OpenDBX resultTimeout) ifTrue: [ (Delay > forMilliseconds: (aQuerySettings timeout asMiliseconds)) wait ]. > > It is not the best solution, of course, but we are limited to FFI > implementation. > > I said "OpenDBX, when possible" because it not depends only in OpenDBX > but also in the client library. Some support this and some doesn't. But > I think most engines support this. I know PostgreSQL does. BTW, which OS > are you deploying on ? RHEL 5.3 + unixODBC + MySQL. BTW, it's not as if ODBC doesn't support asynchronous operations either (see for example http://msdn.microsoft.com/en-us/library/ms713563%28VS.85%29.aspx) if the drivers support it. Unfortunately, I've found that "if the driver supports it" means mostly flipping a coin. Cheers, - Andreas |
In reply to this post by John Chludzinski
Our project is likely to move to MS SQL-Server. I thought ODBC would be a natural? ---John
On Tue, Jan 12, 2010 at 3:49 PM, John Chludzinski <[hidden email]> wrote: Took your all’s advice and switched to the ODBC driver. Works well ! Thanks. ---John |
In reply to this post by Andreas.Raab
On Wed, Jan 13, 2010 at 12:00 AM, Andreas Raab <[hidden email]> wrote:
Thanks for the link. I wasn't aware of that. However, do you know which function does the squeak ODBC driver calls ? because maybe there are asynchronous queries, but the driver is calling the synchronous ones. if the drivers support it. Unfortunately, I've found that "if the driver supports it" means mostly flipping a coin. Yes, true. At least in OpenDBX it always tries to use them if possible. I use to know (I asked OpenDBX developer) which backend and in which OS it could be asynchronous, but I don't find it. Maybe I should ask again. Cheers Mariano Cheers, |
Mariano Martinez Peck wrote:
> RHEL 5.3 + unixODBC + MySQL. BTW, it's not as if ODBC doesn't > support asynchronous operations either (see for example > http://msdn.microsoft.com/en-us/library/ms713563%28VS.85%29.aspx) > > > Thanks for the link. I wasn't aware of that. However, do you know which > function does the squeak ODBC driver calls ? because maybe there are > asynchronous queries, but the driver is calling the synchronous ones. > > > if the drivers support it. Unfortunately, I've found that "if the > driver supports it" means mostly flipping a coin. > > > Yes, true. At least in OpenDBX it always tries to use them if possible. > > I use to know (I asked OpenDBX developer) which backend and in which OS > it could be asynchronous, but I don't find it. Maybe I should ask again. Please do. I'd be quite interested in seeing which combinations are supported. Cheers, - Andreas |
On Wed, Jan 13, 2010 at 12:10 AM, Andreas Raab <[hidden email]> wrote:
And even more, I don't know which ODBC version does the ODBC squeak version supports. This asynchronous queries seems to be from 3.8. Is that supported ?
Done. Cheers, |
In reply to this post by John Chludzinski
MySQL ODBC Driver 5.1 - in my case. ---John
On Tue, Jan 12, 2010 at 6:03 PM, John Chludzinski <[hidden email]> wrote: Our project is likely to move to MS SQL-Server. I thought ODBC would be a natural? ---John |
In reply to this post by Mariano Martinez Peck
Mariano Martinez Peck wrote:
> On Wed, Jan 13, 2010 at 12:10 AM, Andreas Raab <[hidden email] > <mailto:[hidden email]>> wrote: > > Mariano Martinez Peck wrote: > > RHEL 5.3 + unixODBC + MySQL. BTW, it's not as if ODBC doesn't > support asynchronous operations either (see for example > > http://msdn.microsoft.com/en-us/library/ms713563%28VS.85%29.aspx) > > Thanks for the link. I wasn't aware of that. However, do you > know which function does the squeak ODBC driver calls ? because > maybe there are asynchronous queries, but the driver is calling > the synchronous ones. > > > > And even more, I don't know which ODBC version does the ODBC squeak > version supports. This asynchronous queries seems to be from 3.8. Is > that supported ? You're misreading the information. It says prior to 3.8 only statement operations could be executed asynchronously (not connect and some other). I had started to implement async support only to find that the unixODBC MySQL driver doesn't support it. So I dropped it as a waste of time :-) Cheers, - Andreas |
On Wed, Jan 13, 2010 at 3:52 AM, Andreas Raab <[hidden email]> wrote: Mariano Martinez Peck wrote: Yes, it depends not only in the database, but also on the OS. I remember one backend (I don't remember which one) that in Linux for example, it supports async but it doesn't in Windows. It maybe be for sockets functions like select() or something like that :( Cheers, |
Free forum by Nabble | Edit this page |