5 ms·

You really don’t need to know transaction isolation to do the vast majority of work on a typical web app.

taffer 7y ago
I wouldn't say so. Concurrency bugs, like lost updates, can be very subtle and hard to debug, and common databases don't prevent these kinds of bugs by default.
- momokoko 7y ago
  If someone on my team was writing a web app and spending time meddling around with transactions outside of whatever abstraction layer we were using on top of the DB without an incredibly good reason, we'd definitely be having a coaching moment, and if it continued, I'd likely help them find a role with another org where they might be a better fit. Any quality database abstraction provides fairly simple means to perform transactions.
  - vbezhenar 7y ago
    Transactions are hard. You can't just abstract it. Those different isolation levels are there for a reason.
    - vsareto 7y ago
      Just slap READ UNCOMMITTED on everything to get your speed back /s
  - deleted 7y ago
    [deleted]
  - coldtea 7y ago
    >If someone on my team was writing a web app and spending time meddling around with transactions outside of whatever abstraction layer we were using on top of the DB without an incredibly good reason, we'd definitely be having a coaching moment, and if it continued, I'd likely help them find a role with another org where they might be a better fit. And most people with knowledge of DBs should run, not walk, away from a team that operates like that...
    - momokoko 7y ago
      Because if you are writing a fairly standard web app, you don't need this. There isn't the scale to make it important. Software is a very large field, with a wide variety of use cases. Obviously an exchange trading platform is going to have much more focus on these DB issues than a SaaS web app for business that expects at most 5,000-10,000 users at a time. With very few of those user modifying the same records.
      - coldtea 7y ago
        >Because if you are writing a fairly standard web app, you don't need this. Does the app handle user accounts? Payments? Data editing? Multiple logins into the same account? Then it should handle races and transaction properly... That said, it's true that they can be rare, and might be less worth it (engineering or time wise) than just letting it go. For an app with like a few thousands users or internal use, the odds might be small. But a fairly standard web app might serve 1M, or 10M or 100s of millions of people, and they deserve better.
        momokoko 7y ago
        > deserve better So less features and slower performance to account for the hypothetical case where someone tries to edit their user account from 50 devices at once over and over again? > But a fairly standard web app might serve 1M, or 10M or 100s of millions of people You are talking about less than 0.5% of revenue generating SaaS apps.
- ownagefool 7y ago
  I'd argue you should be aware of the transactions and isolations levels exist, like many things, but having to recite them in an interview situation is a different ballgame. Otherwise, you end up in the situation where every second person has a different set of pet skills and you can't hire anyone because they need to know all the skills perfectly. But it depends on what you're doing and your market. I've worked with people who took a pay cuts to go work for FAANG, after several interviews which they've studied for but I've decided it's not really needed when you're just writing a little in house CRUD webapp.
mpartel 7y ago
It can seem that way, but the consequence of not knowing them is lots of subtle race conditions. Granted, most webapps probably don't have enough users to trigger them too often, and the impact is often limited e.g. because the kinds of inconsistencies you can introduce don't actually matter that much in many cases. For the majority of webapps, I'm not sure the default isolation level of MySQL and Postgres is an appropriate tradeoff, since I'd rather have correctness by default than performance by default.
- jackcodes 7y ago
  The vast majority of work on web apps is probably writing CRUD controller methods, proxies to upstream services, or React components. It’s like saying CSS transitions are vital; they aren’t, but probably affect the user experience for the average Joe just as much if not more than a phantom read. At that level of depth you just hand it over to the CSS champ or the DB champ.
  - vsareto 7y ago
    >At that level of depth you just hand it over to the CSS champ or the DB champ. Developers are blaming other developers for not knowing everything they do because businesses forced them to learn everything (Fullstack), but that's actually a bad arrangement and somehow the solution is to just punish the developers more rather than hiring DBAs.
    - vageli 7y ago
      > >At that level of depth you just hand it over to the CSS champ or the DB champ. > Developers are blaming other developers for not knowing everything they do because businesses forced them to learn everything (Fullstack), but that's actually a bad arrangement and somehow the solution is to just punish the developers more rather than hiring DBAs. If the organization views developers as cogs or something like a software assembly line, the desire for interchangeable, unspecialized workers seems like a natural consequence.
  - mpartel 7y ago

I wouldn't say so. Concurrency bugs, like lost updates, can be very subtle and hard to debug, and common databases don't prevent these kinds of bugs by default.

momokoko 7y ago
If someone on my team was writing a web app and spending time meddling around with transactions outside of whatever abstraction layer we were using on top of the DB without an incredibly good reason, we'd definitely be having a coaching moment, and if it continued, I'd likely help them find a role with another org where they might be a better fit. Any quality database abstraction provides fairly simple means to perform transactions.
- vbezhenar 7y ago
  Transactions are hard. You can't just abstract it. Those different isolation levels are there for a reason.
  - vsareto 7y ago
    Just slap READ UNCOMMITTED on everything to get your speed back /s
- deleted 7y ago
  [deleted]
- coldtea 7y ago
  >If someone on my team was writing a web app and spending time meddling around with transactions outside of whatever abstraction layer we were using on top of the DB without an incredibly good reason, we'd definitely be having a coaching moment, and if it continued, I'd likely help them find a role with another org where they might be a better fit. And most people with knowledge of DBs should run, not walk, away from a team that operates like that...
  - momokoko 7y ago
    Because if you are writing a fairly standard web app, you don't need this. There isn't the scale to make it important. Software is a very large field, with a wide variety of use cases. Obviously an exchange trading platform is going to have much more focus on these DB issues than a SaaS web app for business that expects at most 5,000-10,000 users at a time. With very few of those user modifying the same records.
    - coldtea 7y ago
      >Because if you are writing a fairly standard web app, you don't need this. Does the app handle user accounts? Payments? Data editing? Multiple logins into the same account? Then it should handle races and transaction properly... That said, it's true that they can be rare, and might be less worth it (engineering or time wise) than just letting it go. For an app with like a few thousands users or internal use, the odds might be small. But a fairly standard web app might serve 1M, or 10M or 100s of millions of people, and they deserve better.
      - momokoko 7y ago
        > deserve better So less features and slower performance to account for the hypothetical case where someone tries to edit their user account from 50 devices at once over and over again? > But a fairly standard web app might serve 1M, or 10M or 100s of millions of people You are talking about less than 0.5% of revenue generating SaaS apps.
ownagefool 7y ago
I'd argue you should be aware of the transactions and isolations levels exist, like many things, but having to recite them in an interview situation is a different ballgame. Otherwise, you end up in the situation where every second person has a different set of pet skills and you can't hire anyone because they need to know all the skills perfectly. But it depends on what you're doing and your market. I've worked with people who took a pay cuts to go work for FAANG, after several interviews which they've studied for but I've decided it's not really needed when you're just writing a little in house CRUD webapp.

mpartel 7y ago

It can seem that way, but the consequence of not knowing them is lots of subtle race conditions. Granted, most webapps probably don't have enough users to trigger them too often, and the impact is often limited e.g. because the kinds of inconsistencies you can introduce don't actually matter that much in many cases. For the majority of webapps, I'm not sure the default isolation level of MySQL and Postgres is an appropriate tradeoff, since I'd rather have correctness by default than performance by default.

jackcodes 7y ago
The vast majority of work on web apps is probably writing CRUD controller methods, proxies to upstream services, or React components. It’s like saying CSS transitions are vital; they aren’t, but probably affect the user experience for the average Joe just as much if not more than a phantom read. At that level of depth you just hand it over to the CSS champ or the DB champ.
- vsareto 7y ago
  >At that level of depth you just hand it over to the CSS champ or the DB champ. Developers are blaming other developers for not knowing everything they do because businesses forced them to learn everything (Fullstack), but that's actually a bad arrangement and somehow the solution is to just punish the developers more rather than hiring DBAs.
  - vageli 7y ago
    > >At that level of depth you just hand it over to the CSS champ or the DB champ. > Developers are blaming other developers for not knowing everything they do because businesses forced them to learn everything (Fullstack), but that's actually a bad arrangement and somehow the solution is to just punish the developers more rather than hiring DBAs. If the organization views developers as cogs or something like a software assembly line, the desire for interchangeable, unspecialized workers seems like a natural consequence.
- mpartel 7y ago