0

To give an arbitrary example, let's say that I'm storing two objects, Item and Box, in the same database.

These objects have a one-to-one relationship.

Item has the following properties:

  • ID (string)
  • BoxID (string)
  • Price (int)

Box has the following properties:

  • ID (string)
  • ItemID (string)
  • ItemLastUpdated (timestamp)

Whenever Item's price changes, Box's ItemLastUpdated must be updated as well:

try {
    item.price = newPrice;
    itemRepository.Save(item);
} catch (Exception e) {
    // Handle the Exception.
}

try {
    box.itemLastUpdated = now;
    boxRepository.Save(box);        
} catch (Exception e) {
    itemRepository.RollbackLastChange();
    // Handle the Exception.
}

My question concerns the scenario where a database outage causes boxRepository.Save() to fail.

Because itemRepository also uses the same database, it won't be able to rollback its last change.

item's data is now bad because it has stayed modified despite needing a rollback.

EDIT:

Our current architecture cannot use transactions because it is using interfaces to work with databases and therefore cannot assume that a given database has transactions built-in.

If we assume that whatever database we use will have transactions, how do we recode the above code to use them? We are currently using different repositories to work with different tables.

Will creating a "master object" to collate all changes and attempt a transaction suffice, or is there a better way?

8
  • 1
    Can you use transactions? – jonrsharpe Jan 20 '20 at 8:45
  • Relevant: What is atomicity? – John Wu Jan 20 '20 at 8:46
  • @jonrsharpe For this particular project, no. – Floating Sunfish Jan 20 '20 at 9:52
  • 1
    @FloatingSunfish if inconsistent data are unacceptable, use database transactions. What is the reason that you can't use transactions? Technical (hard) or policy (soft, can be overridden if needed)? – Hans-Martin Mosner Jan 20 '20 at 11:06
  • 1
    Modeling the concept of transactions isn't a bad thought. Most databases these days do support them, even some NoSQL databases. For the ones that don't, you can either make the transaction concept a no-op, or simulate their effect for your database. – Berin Loritsch Jan 24 '20 at 13:40
1

Following the advice we got from the community, we have decided to alter our architecture to assume that our database technology will know how to use transactions (or some other equivalent).

We will have a master object that transactions will be fed to. These transactions can contain any number of destructive queries (insert, update, delete) in whatever order the client needs them to occur.

The master object will then attempt to execute said transactions which should guarantee that it's an all-or-nothing operation.

Many thanks to everyone who helped!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.