12

First of all, transaction management should be done on service layer, not on DAO layer as that would create a lot of performance overhead (to deal with appropriate transaction isolation level and propagation at each different method). Also, the scope of a unit of work comes from the service layer instead of the data access layer: imagine performing a ...


10

A UoW might involve one ore more aggregated roots and repositories. No, absolutely not. That misses the entire point. We always change one aggregate at a time (one per transaction). Transactions are typically coordination between the application component and the persistence component. The application starts a transaction (UoW, if you like), reads the ...


9

In its broadest sense, a "transaction" is a group of actions that should be performed as if they were a single "bulk" action. The term is most often used in the context of databases, but it can be applied to many kinds of programs (particularly ones that implement a command pattern). When we're talking about databases, and often even if we aren't, we want ...


9

Its okay to do a 'strict' or a 'nice' version of a delete endpoint, but you need to clearly tell the user what happened. We're doing a delete action with this endpoint. Likely DELETE /resource/bulk/ or something similar. I'm not picky. What matters here is that no matter if you decide to be strict or nice, you need to report back exactly what happened. ...


7

Disclaimer: For the following part, I'm saying most, because I obviously don't have experience with all banking systems. Just like any system which needs to be really fast, even banks are eventually consistent. When you're implementing such system, you really want it to be online as much as possible. Any possible downtime will hurt your business, because ...


6

You need a process manager/saga that do exactly what you need without using transaction that spawn multiple aggregates. Basically that Saga would reserve the ticket right before the payment begins and would markTicketAsSold after the payment is successful or releaseTheReservation after the payment is failed. This process and the invariant that a reserved ...


5

This is diving a little deep into the specific underlying structures of filesystems, which are very complicated and idiosyncratic. But here goes... First, superblocks are not one thing. They differ, filesystem to filesystem, in what information they contain. The two filesystems you mention, extN and btrfs, are much evolved and not all that similar to ...


5

Welcome to the deep, dark recesses of the Concurrency Jungle! This is where many app developers fear to tread--and fear it for good reason. @kdgregory gets it exactly right: This is not one problem, but a very large, very sticky class of problems. Most hard concurrency problems are addressable at scale, with sufficient effort and investment. None, however, ...


5

There are two different questions here, one about the performance behaviour, and one about the auto generated IDs. From my understanding the transaction starts and queues all procedures, until the queue is "released" by using commit() That is only partially correct. When the transaction starts, the database makes something like a "private snapshot" and ...


5

How you cut your transactions is indeed business logic. So let your DAO layer provide a db framework independent API for the transact method you mentioned (and probably for things like commit and rollback). Then you can use it from your BO layer without making it dependent from your database or your db framework.


5

Sorry for the rather long answer. I think, for a modern application approach, you should consider the connection to be injected into the dao, not taken from a factory. Your problem is, as I understand it, that from the perspective from the service layer, you want small grained DAO functionality (CRUD) that should be combined to more complex database ...


5

You state correctly that transactions and locking are needed to deal with shared mutable state. And also that in an actor system, there is no shared mutable state. So it seems you've already answered your question yourself. I see that it can be necessary for some actor to lock one or more other actor(s) to send them several updates such that no other ...


5

In my experience, most questions about transactionability and microservices are caused by the following two reasons: The transactional data is placed in different microservices: This is wrong by definition. Data that should be modified transactionaly belongs to the same service. Grouping the right data in the right service is very tricky and you need to put ...


5

Since you already have a Message Queue, put the message directly on that rather than the db and horizontally scale your Midpoint and App2 App1 -REST-> Midpoint Midpoint (load balanced, multiple servers) Put message on Queue Write Log Send OK Response App2 (multiple queue subscribers) Read message from Queue Process message (...


5

Database keys should not be conflated with business identifiers like invoice numbers or transaction numbers, unless their semantics are identical. The reason you have an ID field in a database is to provide a unique, irrevocable identifier for a record. If that record happens to get removed from the database, the ID for that record is never reused (for ...


5

So the first thing that you have to understand is that real world systems that accounts do not have a single total that is added-to and subtracted from. Instead what they have is a set of transaction records that represent inflows and outflows from an account. Determining the balance of the account is (to oversimplify) reading through all the financial ...


4

First, define use cases for the transaction you are modeling. Define versions of the use case for happy path, and each of the rollback scenarios you wish to model. Each of these use case variations can be presented as a separate sequence diagram. Consider a very simple transaction -- client updates two tables, T1 and T2. Both updates need to succeed, or ...


4

Most database schemes use both! RollBack is the process of undoing changes and reverting to a previous state. This usually occurs either on request when a program detects some logical error and decides the transaction should not take place, or, when the DBMS loses contact with the program before an explicit "COMMIT" has been requested. RollForward occurs ...


4

CC Info was downloaded and then Processed locally (securely). Sometimes Manually, Sometimes Batch, via a dial up line (securely). This is often the case today as well.


4

I find it useful to implement a Service Facade that decouples the implementation of services from the service contract. The Controller from the presentation tier (your MVC stuff) should be able to make a single call to a Service Facade, which then orchestrates the calls to one or more "service" objects/methods, and returns whatever the service contract says ...


4

Yes, it can be made to work in practice. However, it may not be the best approach and is perhaps used as the default option more than it should. In my opinion, SOA became popular as a way of integrating legacy systems as organisations evolved their IT to automate ever larger tasks. It can be very messy but possibly worth it if legacy systems can be re-used. ...


4

From what I've read this does not violate REST. REST has to do with how the client and server communicate with each other; this communication has to be stateless, i.e. the client calls the server and the server responds, that's it, but that doesn't mean there isn't state involved. REST is also about being able to address resources, and resources have/are ...


4

You must distinguish technical correctness criteria from real-world systems requirements. Certainly banks must be able to account for every withdrawal and deposit, and more generally for every in and out on their balance sheets. That's what regulators are for. But no regulator will ever hold a bank to prove that the accounts were completely "consistent" at ...


4

You say: When hitting the "buy button", we generate an unique transaction with all order details and redirect the customer to the payment gateway So why wouldn't you check the customers second purchase against this transaction that you have in your database. Even if it's pending and waiting for the payment it still could be used to block any further ...


4

I would try to solve this with (at least) four document states unprocessed export started (but not under processing) under processing (means: after export finished) processed Moreover, it will be probably a good idea to add a timestamp field to remember when the last state was changed, and as @Bart pointed out, an additional field which user caused the ...


4

Looks like Objectify is designed for atomic-like transactions (Google Application Engine Transactions). It will demand to you to develop your own abstraction of the Transaction Management. In this case. the abstraction goes on How do I delegate the transaction management to upper layers? @DocBrown approach looks to me the faster and cleaner solution to ...


4

How would one achieve something similar to database transactions. Well, you could use distributed transactions, but you don't want to. And, more probably than not, you don't need to. What if these services don't expose APIs to rollback a transaction, what would be the solution? Well, it's great actually, so you won't mess up with distributed ...


4

You pass the same transaction to every participant. Then they use the same transaction and still don't know each other. Obviously, now they (or at least their result) is coupled, but having either all or none of them succeed is the whole point, right? Passing in the transaction is not foolproof (they simply might not use it if they are negligent or mean ...


Only top voted, non community-wiki answers of a minimum length are eligible