Mandatory data storage service: why do I really need a real goal?

Question

I wonder why I really need commitment after the c-store team;

I can understand that committing is a kind of confidence that the message was actually taken under the responsibility of the repository, and the storage takes responsibility, but I wonder why it is not safe to rely on the status of the response ?

I read some explanations about this, but no one convinced me completely. As I understand it, a commit may be required or better desirable mainly because you cannot completely trust the system to which you are sending the message.

Well, it sounds like this: when you insert a record into a database table, you need to check if the record really was inserted, since you cannot trust the database engine ... doesn't it look a little strange? if I cannot trust the database engine, I'm going to replace it with one reliable

Can anyone give a more comprehensive interpretation of the real meaning of the Storage Commitment Service ?

Answer 1

I will try to answer your question with examples of two systems that I worked on in my professional life. Thus, these are not fictitious examples, but practical examples.

Zero footview viewer (early 2000s, still some settings)

When this viewer receives the images, they are not copied to the disc at all. Instead, they are stored in memory and displayed directly to the user. When the viewer is closed, the images disappear from the system that received them.

The success of the C-Store means: I received the images and I can display them.

The storage obligation is not supported by such a system.

Off-site encrypted deep archive

This system has a small local “PACS server” on a site with a small disk capacity used as a buffer from scratch. The local "PACS server" encrypts the images and sends them to an off-site storage center where they are recorded on tape. To ensure the security of bullet-proof data, the data center is mirrored (i.e., copied to another storage center in a different location, which also writes it to tape). The local "PACS server" is a system for which retrieval methods send their images for archiving.

The success of the C-Store means: I received the images and queued them in the storage center

The success of the conservation decision means: I received confirmation from both storage centers that the images were stored on tape. From now on, I will be responsible for saving the images - you will be able to delete local copies.

Obviously, this procedure takes several hours or days (when a large amount of data is transferred: even months). Thus, it cannot be expressed through the success of the C-Store, since in most cases the success of the C-Store image (n-1) triggers the transfer of image n on the client side.

That is why confirmation of the success of the storage and confirmation of readiness for storage are completely different levels of "how safe your images are at the end of the receiver."

When you speak with an off-site backup seller, he states: “We take responsibility for image loss by confirming storage obligations. Since the local PACS server may be damaged before the images are transferred to the storage center, we will not be responsible for the loss of images for which we have not confirmed safety. In other words: the success of the C-Store does not allow you to delete local copies. "

NTN

kritzel_sw

Answer 2

The accepted answer by @kritzel_sw explains all this; I add my two cents:

1] Recommended by IHE

Although DICOM does not mention it as a compulsory service, IHE recommends it.
If your application creates instances and sends them to SCP , you must confirm the use of the storage obligation so that all instances are archived by SCP before they are removed from your repository.

2] Like CStore SCU, you may not know if SCP supports archiving.

Each CStore SCP is not an archiving solution. As also mentioned in the accepted answer, the SUCCESS response from SCP simply means: "I got the data, and I can do my job with it, thanks." SCU could not know if "my job" includes "archiving".

3] CStore SUCCESS's answer is no guarantee of success (in the practical world)

To improve performance, some SCPs send a SUCCESS response before even checking and storing data. When the operation is completed (or may be on another thread), they check the data set and try to save them. At this point, if the validation fails or the storage fails, SCP is unable to report that the storage was not successful.

4] Better than sorry. Read this great article.

This is like a double order. Storage is a transaction, and storage commit is a reconciliation.

In fact, read all of Roni's other articles.