s********r
发帖数: 176 | 1 I am fixing a bug in a project. The existing way to handle the case is
described as below.
There are 2 threads, one uploads(ftp) an image to the file server, the other
thread persist other relative data into the database.
Bug: if ftp image process fails, the new data still is stored into the db,
or if the data is rolled back, the image is still transferred to the file
server.
It is obvious not correct, either of them fails, all fails.
Difficulty: since here are using 2 threads, each is responsible of doing its
separate process so that the whole job is not treated as a unit of work.
I don't think this is a proper design in terms of this work flow.
I wonder the feasibility of making this 2 process all fails or all succeed
in multi-threading environment. If it is feasible, does any one have any
idea of making 2 processes as an unit of work?
Thanks. | g*****g
发帖数: 34805 | 2 It's a bad design to use 2 theads here. The main problem though,
is not that you can't sync between 2 theads, but that upload file
takes a long time while a DB transaction typically is short, it doesn't
make sense to wait until upload is finished to commit the transaction.
Of course if you can still use a compensation transaction to undo
previous transaction. But I don't see why you can't just put them
all in one thread, do upload first, then do db transaction, if upload
fails, throw an exception, if db transaction fails, throw an exception,
catch the exception and delete the partial file if it's there.
other
its
【在 s********r 的大作中提到】
: I am fixing a bug in a project. The existing way to handle the case is
: described as below.
: There are 2 threads, one uploads(ftp) an image to the file server, the other
: thread persist other relative data into the database.
: Bug: if ftp image process fails, the new data still is stored into the db,
: or if the data is rolled back, the image is still transferred to the file
: server.
: It is obvious not correct, either of them fails, all fails.
: Difficulty: since here are using 2 threads, each is responsible of doing its
: separate process so that the whole job is not treated as a unit of work.
| t*******e
发帖数: 684 | 3 Compensation transaction is the last thing you want to do. | s********r
发帖数: 176 | 4 Thanks goodbug for your idea.
I completely agree with you that using one thread to handle the two
processes is the right design.
For some whatever reason, I have to follow the existing bad implementation :
(
Have good Friday.
【在 g*****g 的大作中提到】
: It's a bad design to use 2 theads here. The main problem though,
: is not that you can't sync between 2 theads, but that upload file
: takes a long time while a DB transaction typically is short, it doesn't
: make sense to wait until upload is finished to commit the transaction.
: Of course if you can still use a compensation transaction to undo
: previous transaction. But I don't see why you can't just put them
: all in one thread, do upload first, then do db transaction, if upload
: fails, throw an exception, if db transaction fails, throw an exception,
: catch the exception and delete the partial file if it's there.
:
| s********r
发帖数: 176 | 5 Thank you for the idea.
【在 t*******e 的大作中提到】
: Compensation transaction is the last thing you want to do.
| m****r
发帖数: 6639 | 6 you can have have the file transfer thread wait for the db thread to finish,
and then continue to write the file, and roll back if file transfer fails.
since the db job should be fast, this might not be as bad as it sounds.
other
its
【在 s********r 的大作中提到】
: I am fixing a bug in a project. The existing way to handle the case is
: described as below.
: There are 2 threads, one uploads(ftp) an image to the file server, the other
: thread persist other relative data into the database.
: Bug: if ftp image process fails, the new data still is stored into the db,
: or if the data is rolled back, the image is still transferred to the file
: server.
: It is obvious not correct, either of them fails, all fails.
: Difficulty: since here are using 2 threads, each is responsible of doing its
: separate process so that the whole job is not treated as a unit of work.
| u**d
发帖数: 211 | 7 这就是 two-phase commit
看看你的 application
如果对性能影响不大，还是全部 serialize 比较容易实现
other
its
【在 s********r 的大作中提到】
: I am fixing a bug in a project. The existing way to handle the case is
: described as below.
: There are 2 threads, one uploads(ftp) an image to the file server, the other
: thread persist other relative data into the database.
: Bug: if ftp image process fails, the new data still is stored into the db,
: or if the data is rolled back, the image is still transferred to the file
: server.
: It is obvious not correct, either of them fails, all fails.
: Difficulty: since here are using 2 threads, each is responsible of doing its
: separate process so that the whole job is not treated as a unit of work.
| g*****g
发帖数: 34805 | 8 If you don't commit immediately, you may run out of DB threads while
waiting for file upload. It's worse than compensation transaction.
finish,
【在 m****r 的大作中提到】
: you can have have the file transfer thread wait for the db thread to finish,
: and then continue to write the file, and roll back if file transfer fails.
: since the db job should be fast, this might not be as bad as it sounds.
:
: other
: its
| m****r
发帖数: 6639 | 9 sorry. didn't mean "roll back". first thread need to commit right away.
and the second thread need to undo the commit.
【在 g*****g 的大作中提到】
: If you don't commit immediately, you may run out of DB threads while
: waiting for file upload. It's worse than compensation transaction.
:
: finish,
|
|
