I wonder if there is an easy way to prevent c3p0 connection pool from acquiring connection if provided login information is incorrect? I want it to throw an exception in this case and ignore acquireRetryAttempts parameter.
The reason I'm asking is because RDMS may be configured to block account after a few unsuccessful attempts, and I want to minimize the chances it happens.
Thank you
if you set acquireRetryAttempts to 1, c3p0 will throw an Exception immediately if a Connection acquisition fails, and will not retry until a new client tries to Connect. if you want it not to try again even when new clients come, set the config parameter breakAfterAcquireFailure to true.
see
http://www.mchange.com/projects/c3p0/#acquireRetryAttempts
http://www.mchange.com/projects/c3p0/#breakAfterAcquireFailure
(it would be clearer if acquireRetryAttempts had been named "numAcquireAttempts". sigh.)
good luck!
Related
My app is working with MySQL database, to connection I'm using FireDAC components. Last time I have got a network problem, I test it and it is looks like (time to time) it losing 4 ping request. My app return me error: "[FireDAC][Phys][MySQL] Lost connection to MySQL server during query". Now the question: setting fdconnection.TFDUpdateOptions.LockWait to true (default is false) will resolve my problem or make new problems?
TFDUpdateOptions.LockWait has no effect on your connection to the database. It determines what happens when a record lock can't be obtained immediately. The documentation says it pretty clearly:
Use the LockWait property to control whether FireDAC should wait while the pessimistic lock is acquired (True), or return the error immediately (False) if the record is already locked. The default value is False.
The LockWait property is used only if LockMode = lmPessimistic.
FireDAC can't wait to get a lock if it loses the connection, as clearly there is no way to either request the lock or determine if it was obtained. Therefore, changing LockWait will not change the lost connection issue, and it may slow many other operations against the data.
The only solution to your lost ping requests is to fix your network connection so it stops dropping packets. Simply randomly changing options on TFDConnection isn't going to fix networking issues.
I have a WCF Data Service that uses a DBML file to generate all the code required for my DataContext. My database is running on the SQL Azure Business tier (so still using the shared model) and I am using the Transient Fault Handling Application Block to wrap all my calls.
The problem I'm seeing is that I'm still getting a number of SqlExceptions around "timeout expired". My retry policy hooks into the Retrying event to log any retries but i never see anything in my logs except the timeout exception.
From my research it looks like the Retry block only retries the query and assumes it has a reliable connection. However, since i'm using a DataContext I don't actually have control of setting up that connection and since all my existing code is Linq2Sql I don't want to switch it.
Am I missing something simple? There doesn't seem to be any way to tell the DataService that the CurrentDataSource should be a reliable connection or anyway to use the RetryManager to use a policy on the connection itself.
Here's an example of one of my ServiceOperations:
[WebGet]
public MyTable GetDetailsById(string id)
{
try
{
var detail = retryPolicy.ExecuteAction<MyTable>(() =>
CurrentDataSource.MyTable
.Where(l => l.id == id)
.FirstOrDefault());
return detail;
}
catch (Exception ex)
{
Trace.TraceError(ex.Message);
}
}
Any ideas?
Update: My query doesn't take longer than 30 seconds.
Command timeouts occur when the client is not getting a response from the server within x amount of seconds. The is not a transient error and hence not handled by the retry logic. The general recommendation is to change the command timeout to at least 30 seconds for Azure SQL Database. In addition, if you have long running queries, you should consider to increase the timeout for these queries beyond your application wide default.
Documentation on how to set the command timeout can be found here.
I have an app that requires local users to Sync back to the SQL server periodically (event based, including upon Close/Exit).
My users have occasional internet/VPN issues that throw the expected "3146" error.
Problem:
When ODBC error is thrown, my app LOSES its mind (global variables are lost, etc.) and the app becomes utterly unusable. There are many subsequent layers of error messages thrown to my users, occasionally requiring a Ctl-Break to interrupt (or task manager).
Question:
I have an err_handler in every module that provides a structured error message. I am able to trap err_number "3146" in the err_handler module, where I attempt an abrupt "Application.Quit" (to avoid the subsequent err messages). I still get a couple subsequent err messages before the application fully terminates.
Is there a better approach to more gracefully handling "3146" errors?
Looking for some good ideas.
Thanks!
If you are handling the error then there should not be a problem. How you should be handling the error is to not do Application.Quit, you should actually do something about the error. A failed connection is not a reason to blow up your app.
Instead, think about caching data locally so that when the connection can be made you can perform your sync again. When you discover your connection failed, stop trying to connect, abort the syncing process, and tell your users "Hey, we couldn't sync now. You might be having VPN issues. Fix those and try to sync again." And all the while your data are still stored in your accdb so that if they go into work the next day and are hardwired into the network they can then sync successfully.
I have a set of web services (the server), and an app which consumes this (client). In this sort of relationship, should the server always throw exceptions (ie in the throw block, rethrow the caught exception), and the client catch this. Exceptions which the server can handle, it will deal with and not rethrow, but everything else will be thrown to the calling layer for further action (the consuming app can raise a msg box or whatever).
Is this a good example of an exception that can be dealt with: A file cannot be written because the directory requires special privileges, so if this raises an exception, the file is written somewhere which does not require admin rights.
Thanks
There are more than one type of error.
For errors that the client can correct and retry, give them instructions on what to correct.
For other errors, where retrying will make no difference, such as an unauthorized action, let the user know why they can't perform the action, and if there's anything they can do to change the matter.
As you suggested, if the client issues a request to update the record, and something on the server, out of the control of the client, occurs, but the server can recover, then don't notify the client. If you need to know, then have the server notify you.
If the error occurs on the server, but the server isn't able to recover, you definitely need to notify the client of the failure and to either notify you, or try again later. Again, the system should notify you.
That particular error sounds like a configuration problem on the server, so the client doesn't have any means of action and shouldn't be given that information.
I generally cover that kind of error under a generic error message ("System error, please contact your system administrator") and log the error on the server (for later inspection).
I have a MySQL gone away with Django under WSGI. I found entries for this problem on stackoverflow, but nothing with Django specifically. Google does not help, except for workarounds (like polling the website every once in a while, or increasing the database timeout). Nothing definitive. Technically, Django and/or MySQLdb (I'm using the latest 1.2.3c1) should attempt a reconnect if the server hanged the connection, but this does not happen. How can I solve this issue without workarounds ?
show variables like 'wait_timeout';
this is the setting will throw back the "mysql gone away" error
set it to a very large value to prevent it "gone away"
or simple re-ping the mysql connection after certain period
Django developers gave one short answer for all questions like this in https://code.djangoproject.com/ticket/21597#comment:29
Resolution set to wontfix
Actually this is the intended behavior after #15119. See that ticket for the rationale.
If you hit this problem and don't want to understand what's going on, don't reopen this ticket, just do this:
RECOMMENDED SOLUTION: close the connection with from django.db import connection; connection.close() when you know that your program is going to be idle for a long time.
CRAPPY SOLUTION: increase wait_timeout so it's longer than the maximum idle time of your program.
In this context, idle time is the time between two successive database queries.
You could create middleware to ping() the MySQL connection (which
will reconnect if it timed out) before processing the view
You could also add middleware to catch the exception, reconnect, and retry the
view (I think I would prefer the above solution as simpler, but it should technically work and be performant assuming timeouts are rare. This also assumes a failed view has no side effects, which is a desirable property but can be difficult to do, especially if you write to a filesystem as well as a db in your view.)