When inserted into the database code, try to catch a DuplicateKeyException abnormalities, colleagues suggest first check the database first

CodePudding user response:

The need to see the actual business scenarios, basically see your business is how to insert data, if it is a front import, should first check the data? If other way to import, can consider to duplicate records skip or update? Because some business can not be thrown exception directly to business interruption, will ask only once, for example, direct throw exceptions will lead to the normal data will be lost, so the price is still the business and technology solutions for business services, simply discuss technical solution to have what meaning,

CodePudding user response:

First query is certainly soon don't have the same key to insert the same key is generating a new key, if you're not can be directly try catch key when there is no question of your operation, so if you have the same key to appear in the input into how do you make up for, and if there is a nested transaction you inserted the exception to capture someone else in time for me to call you inserted into the interface of his without you there is an error you turn anomaly captured it's transaction successful people will think you are successful

CodePudding user response:

Not throw exception code is big,
But repeated injection, it should be the final out, try to avoid relying on the ability of the database, in the code to get rid of,
If you don't support the only index database design, how to do?

CodePudding user response:

Is I didn't express clearly, is the database design of a field, called the ACCOUNT is the only index, in simple terms the front-end calls will transfer the ACCOUNT and PASSWORD, so I catch in the code DuplicateKeyException this exception, colleagues are suggested in the try catch first to check the front travels outside the ACCOUNT exists, if there is a direct return, don't need to try again in the catch

CodePudding user response:

Try to stop the JVM to rearrangement of the code, in the case of abnormal need to a snapshot of the stack, recording stack frame points to the name of the class, the method name... And so on, there is a performance impact

CodePudding user response:

When an exception occurs, the system will help address some things, it would take some performance, so in high performance scenarios, try not to an exception occurs (such as to determine the divisor is 0, is not 0 then in addition to the operation, can avoid throwing was 0 except exception).

CodePudding user response:

RiskyChan

reference 4 floor response:

I didn't express clearly, is the database design of a field, called the ACCOUNT is the only index, in simple terms the front-end calls will transfer the ACCOUNT and PASSWORD, so I catch in the code DuplicateKeyException this exception, colleagues are suggested in the try catch first to check the front travels outside the ACCOUNT exists, if there is a direct return, don't need to try again in the catch

The business process, of course, is in accordance with your colleague says, first, to prevent errors; Rather than wait for database error handling errors again, very unfriendly. Their repetition and the data presented is also query the database; So for the database, because you use the connection pool, don't have to worry about multiple connection time consuming problem;

CodePudding user response:

From a business perspective, certainly need to do first check uniqueness, returned to the user prompt information! But in the case of high concurrency, conflict cannot avoid completely off the primary key of the qing, this in database level control, database data more clean

CodePudding user response:

refer to the original poster riskyChan response:

code when inserted into the database, and try to catch a DuplicateKeyException abnormalities, colleagues suggest first to check the database

The cost of the building Lord, throw exceptions is smaller than a database query, actual programming in the process, you feel an exception is slow, is an illusion,
The bottleneck of the problem is that you write inside the catch block of e.p rintStackTrace () function call, obviously, the performance of this function call is very low,
On the one hand, to scan thread stack, gather together all associated information and function information; Print, on the other hand, need to use IO operation, the performance is also very low,
If you don't believe, you can do an experiment, inside the catch block, don't do any IO operations, take a look at is the database query is fast, fast or throw an exception,

Throw an exception is slower than object across a function call, but the absolute speed faster than any IO operations, including database access operations,

The crux of the problem is you how to handle the exception thrown when we in the design process, also avoid IO operations, if can not avoid, consider optimizing IO operations,

CodePudding user response:

RiskyChan

reference 4 floor response:

I didn't express clearly, is the database design of a field, called the ACCOUNT is the only index, in simple terms the front-end calls will transfer the ACCOUNT and PASSWORD, so I catch in the code DuplicateKeyException this exception, colleagues are suggested in the try catch first to check the front travels outside the ACCOUNT exists, if there is a direct return, don't need to try again in the catch

The idea is right, the premise is the whole block of code do not need to check the password, if is the login logic, it can't just rely on judging the account login is successful,

We want to consider, under normal circumstances, or, big probability, the business logic of the block of code that you, used to improve the performance of the whole block of code,

CodePudding user response:

references to the tenth floor, ice rain response:

Quote: refer to the original poster riskyChan response:

code when inserted into the database, and try to catch a DuplicateKeyException abnormalities, colleagues suggest first to check the database

The cost of the building Lord, throw exceptions is smaller than a database query, actual programming in the process, you feel an exception is slow, is an illusion,
The bottleneck of the problem is that you write inside the catch block of e.p rintStackTrace () function call, obviously, the performance of this function call is very low,
On the one hand, to scan thread stack, gather together all associated information and function information; Print, on the other hand, need to use IO operation, the performance is also very low,
If you don't believe, you can do an experiment, inside the catch block, don't do any IO operations, take a look at is the database query is fast, fast or throw an exception,

Throw an exception is slower than object across a function call, but the absolute speed faster than any IO operations, including database access operations,

The crux of the problem is you how to handle the exception thrown when we in the design process, also avoid IO operations, if can not avoid, consider optimizing IO operations,

Abnormal price significantly larger, you need to deal with abnormal, need consider the abnormal operations attention; The meaning of the original poster is the database insert when he repeated judge and query the database first to judge the only insert both compare, again through the primary key to query a few milliseconds, simply don't have to consider, on the contrary if the program thrown exception this is very scary,