Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Since you're using primary keys and not ranges, it should be row-level locking. There's also the concept of a shared vs exclusive lock. Shared locks allow other processes to still read the data while an exclusive is used in an update/delete scenario and blocks all others from reading it.</p> <p>On the logic in general.. if there's really only <em>one</em> place storing the credits and <em>one</em> place reading them, how important is it to sync in realtime? Would 3, 5, or 10 seconds later be sufficient? If Site 1 is completely down, do you want to allow for Site 2 to still work?</p> <p>Personally, I would restructure things a bit:</p> <ul> <li>A user creates an account on Site 1.</li> <li>The first time a transaction is done on Site 2, it validates the account exists on S1 and gets the number of credits.. and keeps it.</li> <li>Whenever a transaction is done on Site 2, you check the local credit count (cache) first and <em>if there are enough credits</em> you return a <a href="http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#2xx_Success" rel="nofollow">202 Accepted</a> response code. It basically means "hey, we accepted this but aren't done with it yet."</li> <li>You can immediately allow the user to continue at this point.</li> <li><strong>But</strong> at the same time you did the local credit check, you made another request to S1 with the actual transaction.</li> <li>Hopefully, that service can give you a success/failure message <em>and</em> the update <strong>definitive/official</strong> credit count.</li> <li>Using that, you update the local transaction status to 204 NO Content (success) and update the cache for the next time.</li> </ul> <p>Since S1 is always returning the definitive current credit count, you don't have to worry about maintaining the credit count on S2 in a 100% accurate way.. you can just wait for it from S1.</p> <p>If you're <em>really</em> nervous about it, you could have a job that runs every N hours that polls S1 requesting updates on every account updated during that N hours.</p>
    singulars
    1. This table or related slice is empty.
    1. POInnoDB transactions and REST
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USCaseySoftware
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThe things I want to make sure never happen are race conditions and failure at either ends which can cause transfer of credits but not actual purchasing of service or the other way around. Does your approach cover that?
      singulars
      1. PO
      1. USVladimir
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload