Hello, good morning, good evening, good afternoon wherever you are in the world and welcome to the second re-testing resetting digital currency succession of the World Economic Forum's DABOS agenda. I'm Michael Casey. For the past year, I've been the Chief Content Officer at Coindesk. Before that, I was at the Digital Currency Initiative at MIT Media Lab. Before that, a writer at the Wall Street Journal. It's an honor to be moderating this discussion with an esteemed panel whose experience spans both national and multilateral government, as well as academic and non-government leadership. Before I introduce them, I'd like to put this conversation in what I see as the right context. What excites me about digital currencies, why my team and I at Coindesk are privileged to be covering this topic every day, is that it isn't just your standard story of a new technology disrupting our lives, this isn't mp3 music files disrupting CDs. We're talking about the disruption of money, a technology so deeply rooted in the structural society that we so often just take it for granted. Whether we're talking about cryptocurrencies such as Bitcoin or, if we're talking about central bank digital currencies, as we will mostly be doing today, this isn't just another digital upgrade to our existing bank-centric system of money. With digital currencies, the money itself is software. It's programmable. And when that happens, a lot of our assumptions about what money is and how it functions may need to be reexamined. This disruption is likely to be challenging. And to add to those challenges, it is coming at a time of profound stress in the global economy, with governments racking up huge debts to cover the costs of COVID-19 relief, and central banks adding unprecedented monetary liquidity to the global financial system. It's also happening at a time of growing institutional interest in Bitcoin and other cryptocurrencies, which, whether you like it or not, are a part of the shifting monetary landscape. We'll discuss that and more today. The session starts with a 30-minute public panel discussion. It will then be followed by a more detailed conversation with forum members and partners. So now let me introduce this tremendous panel. We are joined by senior minister of the government of Singapore, Tharmin Shanmugaratnam. Before his important position in Singapore, which includes chairmanship of the Monetary Authority of Singapore, senior minister Tharmin has been a very active participant in international financial governance committees at the IMF, the G20, and the UN, all in senior positions. Welcome, senior minister. Next we have Dr. Xu Min, chairman of National Institute of Finance and Research in the People's Republic of China. Among a variety of important past positions, Dr. Xu has also been the Deputy Governor of the People's Bank of China and Deputy Managing Director of the IMF. Welcome to you, Dr. Xu. And last but not least, we have Dr. Sara Panteleano, who is Chief Executive of the Overseas Development Institute. In a wide-ranging international career in humanitarian and development work, she has led and served on numerous boards and committees for various national NGOs and UN bodies. Welcome, Dr. Panteleano. It's important to note that all three speakers have been actively involved in the World Documentary Forum's digital currency governance committees. So I'd like to turn to Dr. Xu first, because it's fair to say that the most hotly anticipated development in digital currencies at the moment is the CBDC being developed by the People's Bank of China. Dr. Xu, from your unique position to view that development, could you please walk us through where things stand with this project? What is the Chinese government's intention here? What is the purpose here? And can you give us a sense of the timeline? When might we expect the digital currency electronic payment system, as it's known, to go live? Well, thank you. First of all, I thank you for the invitation, and it's a great, great honor for me to join this very distinguished panel. We conducted two tests, as many people know, one in Shenzhen, one in Chuzhou, and on the digital currencies and small scale. In Shenzhen, roughly about 10 million RMB, as sort of for consumption, coupon free to the people, people can, you know, require and get them and they can spend money in around 3,600 shops and various, you know, the agents.  The whole thing, it looks like it's sort of for residential, it's a consumption type of things, like retail. But I think there are few features within the system. The first issue is defined by M0. In the first two tests, they are retail, but if you think about it, if you define by M0, it's still in the very early stage of CBDC, but you still can imagine many, many occasions and many, many scenarios you can apply. For example, the credit to SMEs, you know, for example, the salary payments to the public servants or, you know, to special subsidies and support to the people who need the Medicare or others. So you can imagine hundreds of different occasions you can apply to use and the CBDC to improve the efficiency, and transparency, and improve the public policy transmission mechanisms. I think that's the key issue. M0 is a very early stage, but it's due importance of many roles. It also has a secondary structure. It is, although at the end you see as retail, it's not because central bank will give the digital currency to the banks, for example, in the second case, involving four major commercial banks in China and one e-commerce platform. So those agents were on behalf of central bank, people bank of China, and to solicitate, you know, to get applications, to get people to distribute the digital currency to the people. So central bank does not direct it to the retail in the sense to the customer. So it's a two-layer structure and makes it easier in terms of building the system, building the backward office, and also building a sort of controlling system in a clear and relatively less cost and architectures. So I think the best case is we'll continue to do more tests, expand the scope, is not increase the size, but increase more occasions, scenarios to apply for the various usage, to test the system, sustainability, durability, accuracy, efficiency. I don't think that we have a particular, you know, and a timeline as Mark you mentioned. So we just try to step, step to carefully to test the system because for financial and also public service, the security, the stability is the most important thing. But I think even from a very beginning point, M0, the potential for use is central bank digital currency in the real economy is a huge. Yeah, I mean, it makes perfect sense that you would take this gradually and see how it goes because the impact, as you say, could be huge. And so we need to be patient. But the world is going to be watching with bated breath to see how it rolls out. Dr. Thurman, you know, of course, China is not the only country that has embarked on a CBDC project. And the way that doctors who described it very much a focus in their case, at least to start with on this retail facing model, and the incorporation of that into e-commerce and other things as they go along. But Singapore, of course, has also been actively exploring this technology. And you've been really ahead of the curve in terms of wholesale CBDCs. So with that in mind, what use cases do you see yours and other CBDC projects contributing to? And also, we're talking here about, in China's case there, about what happens within China. But there's this bigger question about how will they be used across borders? And what risks and opportunities may lie for that cross border commerce with this technology? Thanks, Michael. Maybe just to take a step back, I would say central banks, the majority of central banks, are now actively exploring the issue of central bank digital currencies. But it's not a foregone conclusion that most central banks will issue CBDCs, be they wholesale or retail CBDCs. The fundamental issue that we are responding to is the rise of e-commerce, the upending of whole industries as a result of digitization of payments, sales, delivery. And together with e-commerce, you now have new means of payments and new payment providers that are emerging. So the old world of cash on the one hand, notes and coins, and bank account based payments, the traditional two tier payment system comprising the central bank and commercial banks. That old system is being disintermediated by new players, but the biggest and most fundamental driver is in the real economy. E-commerce is now a major force. And the old world of currency needs to catch up with this new reality. The second thing that central banks are responding to comes out of the first, which is that there's been tremendous innovation in the private sector, particularly outside the banking system. In the first instance, new non-bank players have emerged in some cases, like in China, as formidable competitors. In many other places, they are the most, very often, the most innovative players and the fastest growing players. That horse or that set of horses has bolted the stable and central banks are now trying to figure out how they intervene in that race. That's the second major change and the last 10 years especially have seen that whole new horse race starting. Now, inherent in the network economics or the network externalities that come out of both e-commerce as well as these new private payment systems or ecosystems is that there's an advantage in market power. The more competitive you are, the bigger you get and the bigger you are, the more data you have from consumers and the more market power you acquire. There are serious issues to do with emerging monopolies, not yet present globally, I would say, but that's where it will come to and of course China is a very good example. Also serious issues to do with the fact that these are typically, as they get larger, closed loop ecosystems. They are walled gardens in other words and what we have to do in the interest of a vibrant competitive and efficient payment system is to restore biodiversity. You can't have walled gardens constituting your national payment system. You need biodiversity and you need interoperability and that's where we are coming into it as central banks. It's not so much about CBDCs, central bank digital currencies per se, but about what we do about this whole new innovative landscape. We don't want the race to stop and I think our attitude should not be at this point to pick which horse is going to be the winner. Our attitude shouldn't be to try to halt the race. We should want, in fact, a new dark horse in the system which is existing bank-based payment systems waking up as many are doing, certainly in Singapore the banks have responded very well, bank-based payment systems becoming as efficient and as competitive as these new players are. Reducing costs, speeding up transactions, offering better service to consumers. That too is happening and in fact the banks were really the first in the game of running real-time payments domestically amongst themselves, but this new dark horse is also now in contention and I'll aim, I think, at central banks and as financial policymakers should we, to not close our options at this stage, stay open-minded and we should not try to crowd out entirely the private sector players, those private sector digital wallets, tokens or stable coins. Don't crowd them out entirely because they've been a source of great innovation, but they cannot be left of their own. The payment system is a public good, it needs to be regulated, it needs to be interoperable, it needs to be safe, including safe from cryptographic incursions and it needs to have the necessary transparency to avoid the risk of money laundering and illicit finance and remember most studies show that roughly half of all bitcoin transactions have something to do with illicit activity. That's the first objective, don't crowd out this whole new set of players too quickly. Second, don't disintermediate the banking system and the risk of some conceptions of central bank digital currencies, particularly retail CBDCs, is that they can seriously disintermediate the traditional banking system, take away their source of funding because people would rather put their money with a central bank instead of with a bank, particularly in crisis or particularly when a crisis is incipient. It's very easy for people to switch money into a central bank if you have that cheap, easy, at a click of a button option or putting your money with a central bank instead of the banks and that will be very dangerous for the whole system. If we do have a central bank digital currency, which I think is still a option on the menu, not yet decided in most cases, it should make sure that it avoids crowding out entirely the private alternatives with the new stable coins and tokens, also make sure it avoids disintermediating the banking system and where possible allow for greater private sector competition. In fact, it's quite interesting because new players in payments may find it easy to ride on a central bank digital currency, offer smart contracts of the luck and they don't need to invent their own e-money, they don't need to go around acquiring merchants, they just ride on a central bank digital currency and offer their own services. Even in countries which are relatively unbanked, in other words, where the traditional banking system hasn't reached very far, particularly in rural populations, there are very interesting examples of central banks who are now experimenting with CBDCs that come together with bank accounts. So in Cambodia, for instance, which has high mobile and e-money penetration but is a relatively unbanked population, the new CBDC wallet which the central bank has introduced comes with a bank account linked to it. Very interesting option. So think of the world we are moving into in hybrid terms, not one or the other, not one or the other between the non-bank, private stable coin players versus the existing banks, know about the central bank digital currency displacing either of those two. Think of it in hybrid terms and how we can get the best synergy but regulation is going to be necessary. This is a public good, the payment system is a public good and we've got to ensure that we have interoperability, we have safety and we have the degree of transparency that is necessary including identity, digital identity that is necessary to curb illicit finance. Fantastic, senior minister Thamon. I don't know whether you may well have heard the previous session that we had in Bank of England Governor Andrew Bailey was maybe taking a slightly different position being that CBDCs would actually rise to ultimately make these private and different systems go away that they would basically outcompete them. Interesting that you're recognizing and keeping that option open and ensuring that there is this private competition, this bigger environment of competition. But I think it's most interesting and Dr. Pantoliano senior minister Thamon has set you up quite nicely here is that he also mentioned the idea that these ecosystems in this competitive hybrid environment he was talking about money starts to become an aspect of market power that your money now, your currency in some respects is an instrument of gathering power through the networks that they create. And that I think raises interesting challenges and opportunities for developing countries. He mentioned there of course there is this potential in these countries to perhaps leverage these existing systems and build on top of them. But of course developing countries who as he mentioned are many of them exploring these technologies have a whole set of different circumstances. They don't have the financial and technological resources that a country like China or like Singapore has. And of course they've been especially hard hit by COVID. So from where you stand, do you see CBDCs also cryptocurrencies and other elements of blockchain technology stablecoins were mentioned. Do they allow these countries to leap from the technology barriers that they currently face and address the economic challenges that they've had in the past but now face seriously in terms of this COVID-19 pandemic? Or does that competitive challenge that senior minister Thamon was referring to exacerbate the financial challenges that these countries face? Thanks Michael. So let me explain why the system we have now doesn't quite work and why we really need to leverage that competitive empowerment in trying to find ways to make it work for people. The current system doesn't allow everyone to acquire a bank account. In middle and low income countries, financial institutions are not easily accessible. They're not robust. They very often leave people to rely on cash to rely on barter to borrow money to collateralize loans or informal institutions like the microfinance organizations that we see in many countries, the cooperatives. And even people who have bank accounts are actually underbanked. They don't have access to the full gamut of financial services, loans, mortgages and brokerage accounts. And actually I would argue that this is not just in low and middle income countries. This is a problem even in our developed economies for some of the poorest in our societies. They've got very high logistical costs for the finance industry, but also for the consumer that often, especially in remote rural areas, doesn't have access to banks or has to really incur profound costs to access ATMs or banks. And so the digital payment system can help reduce these logistical costs, can help remove the dangers of holding cash, can help reduce the gender pay gap in financial access, which actually remains deeply persistent in low income countries at about nine percent. And we have positive stories from the Philippines where women's digital financial access actually is greater than the men's in Bangladesh, where women government workers are using digital access to receive wages more safely and conveniently. And they can really help facilitate remittances, which are actually the largest source of external financing in low and middle income countries. We have an annual remittance flow of about $529 billion dollars. They can be as much as 35 percent of GDPs in some countries according to the IMF. But remittances prices are very high. They're high because of underdevelopment financial infrastructure, because of limited competition, because of regulatory obstacles. So CBDCs in particular have the potential to create a domestic and cross-border payment transfer system that is fast, that is efficient, that is much cheaper. And they can actually be utilized by the full value chain for person to person, business to business, and business to consumer transactions. And they can also help create a financial identity and a credit history. There's actually a big problem for many people. They are historically excluded from private institutions. Another advantage is savings. That could be improved through the adoption of CBDCs as an instrument that can allow money to be stored easily, immediately, and securely. But CBDCs, if we really want to see them make a transformative contribution in this space, need to address three critical issues. The first is access to the internet, because in many low and middle income countries, internet communication infrastructure is very low compared to many other contexts. We see internet penetration just in the urban areas, where at least a 3G network is about 90 percent. So we need to be careful that this doesn't exacerbate further divide and digital exclusion, particularly for people in rural areas. So if countries are seriously considering the introduction of CBDC, they need to make sure that they first build affordable internet infrastructure and mobile wallets for CBDC transactions that can operate in low bandwidth areas. The second is the level of digital adoption, because only 3.5 billion adults in the world have access to a smartphone out of 8 billion. And even though we can only imagine that smartphone penetration will increase very rapidly, it will not reach 100 percent soon. So before governments turn to CBDCs, they must work with mobile providers to increase smartphone penetration rates. And finally, digital and financial literacy, it will be critical to help people understand and trust the technology, allay issues around data security, help people become more familiar with the technology, improve the financial literacy of people. So I actually think that CBDCs have the potential to be hugely transformative, but they need to be designed with the end user in mind, especially those who are currently financially excluded. So lots to unpack there as well. And maybe Dr. Zhu, this is an opportunity to think about China's role in the international community with a lot of developing countries that engage with China through trade and obviously China's investments as well. I'm interested to know what is the plan for the digital R&B in terms of how it fits into China's international strategy, for example, into the Global Belt and Road Trade Roots Initiative. We know that China has long been interested in internationalizing the R&B and in giving it a greater place in international commerce. So does a digital version give China a bigger opportunity to compete with the U.S. for that role, and if so, how? The first issue is I don't think it's a plan. The second is I don't think it was thought of for an instrument to compete with the dollar. And the currency competition is a very vague unclear concept, both in economic theory and also in practice. So I don't think that the digital currency will move into that direction. However, the digital currency can and will move across the board, which is very much lead and driven by market with trade flows, with payments, and with all the cash flow or capital flows, and with currency exchange. So all those things will go, but it's really much depends on the market. And also, I think it depends on the countries, the authorities' agreements, the government's agreements. And so here, if Singapore willing to have the Chinese digital currency move into Singapore and China willing to accept the Singapore digital currency, maybe two countries can sign a deal to work on those things. But respect the integrity of the country, I think this is also very important. But in the business, the market will drive the digital currency move into a different area. I think if that's the case, we will see and will happen. If you don't mind a little follow-up question here, Senior Minister Tharman was talking about interoperability and you there were alluding to it as well, the potential for agreements across borders for these currencies to be able to exchange with other, with, as you said, respect for the integrity of the system. There's a lot of focus on China's model, and we've had, for example, former CFTC chairman, Christopher Giancarlo, promoting a digital dollar in the US. And the idea that he's arguing is that the dollar will be more appealing, say, than the digital RMB in his argument, because there's better privacy protections. I'm just wondering, in the context of this interoperable cross-border arrangement, what guarantees, if any, can China give that this digital version of your currency won't have those privacy concerns that people are talking about so much? Well, I mean, since this is a sovereign digital currency, so this is really on the legal base equivalent to whatever the physical RMB. So I think that's the basic coordination for the digital currency to any foreigner who want to hold the digital currency of RMB as well. I really don't see that's a big issue. Obviously, if you go one step backwards, the internal architecture, internal technology, and can be very different. So the way it's used and transformed, and also the technical networking path also can be very different. So are those issues need to be solved when the market gradually developed? Okay. C. Mr. Thamman, you heard the reference there from Dr. Xu about interoperability with Singapore. Now Singapore has played, I would say, a leading role in setting an open regulatory approach to cryptocurrencies, to blockchain technologies, and you were alluding to that in your prior comments as well. What happens, though, on the international stage? How do we arrive and should we arrive at some sort of globally consistent standard for this regulatory framework? And what role will Singapore play in contributing to that global agenda? Do you think that you have an opportunity in this environment to take leadership? Or do we go back to a scenario that Dr. Pantaliano and I were talking a little bit about, in some respects, the big country set the rules, the US, of course, being the elephant in the room here. Where do you see this international process going? Well, I think, actually, payment systems are a very interesting example of how, I wouldn't say multilateralism, but a broad set of international players are now actively collaborating with each other. International regulators and central banks are actively collaborating with each other. And the roadmap, we all want to be on as we explore this rapidly changing landscape or as we traverse this rapidly changing landscape. The FSB, working together with the G20, has been in the lead and Singapore has been a very active member of these working groups. So I would say, if I compare it with some other aspects of international affairs, this area is actually working fairly well. You've got a set of players around the table, large countries and small, who have a common interest. Central banks tend to think roughly alike, a common interest in safety, stability, efficiency, resilience. And that process has been, has already gone forward a fair bit. But one issue that really happened, resolved, is the whole issue of integrity of different international systems or what the economists would call monetary sovereignty. In the traditional world, we already had a problem. Small developing countries were always at risk of what was called dollarization of their economies. There's a major country currency, the US dollar being the most prominent, which is always available to firms and consumers of that country. And whenever there was a hint of sovereign risk and there was worries about whether the central bank would run out of reserves, people would just start switching into dollars. And there are some economies today where the dollar is still a major unit of transaction and a store of value. Now that, which is a traditional risk, will become much more pronounced if you have a digital currency, because it'll be that much cheaper and faster to switch from domestic currency assets into foreign currency assets. And it's an issue honestly that we haven't begun to address. And it's one of the concerns we should have when we think about central bank digital currencies, particularly for major countries. So I would say that's an issue that's not just regulatory in the sense of financial regulation, it's a monetary policy consideration that we do have to address. But otherwise, I would say moving ahead, the roadmap must involve moving ahead so that we have not just domestic interoperability, but we have international interoperability, both for retail payments, remittances and the like that Dr. Patulano was talking about, as well as addressing the whole issue of identity. In other words, everyone would love anonymous transactions, but we know what happens with anonymous transactions. You do need both domestically and internationally to have identification, unique digital identities. Now it doesn't necessarily have to require a central bank digital currency. And I'm sort of coming on top of what Dr. Patulano was saying. You can have publicly provided digital identities like the Indians have had through the ARTAR system, combined with open API systems. And you can have interoperability and financial inclusion. So it doesn't necessarily come with the central bank digital currency, which is the train on top of the rails. You can actually have private trains running on top of a publicly provided rail. But internationally, that too will remain important agreeing amongst regulators on the principles and requirements to ensure that you don't have anonymity and that you do have traceability or transactions in a world where, you know, let's face it, illicit activity will remain a fact of life for a long time to come. Safety is a whole big issue in the face of cyber risks. It's a huge issue. And one of the reasons why I myself favor this biodiversity in favor of not having one big dominant central bank digital currency solution even within our own countries, let alone internationally, is that you don't want the whole system blowing up at once. It's a rapidly changing field. Those who are involved in cryptographic crimes have a lot of talent and innovative capabilities. It's a constantly moving field. And you do not want the whole system blowing up at once. Sorry, just because we want to get one last question in here to Dr. Paolo Piano. Thank you very much, Seniors. Because there's a huge pile of stuff to unpack there. We're going to have to take this into the forum discussion. But just before we leave this public section, Dr. Paolo Piano, a lot of stuff that Senior Minister just laid out there and the vulnerability in some respects of developing countries to this problem in some respects of the dependence on the dollar and so forth. In light of that, what do you see the most important considerations lying with regards to the regulatory approach that the world should be taking to this? I think just to pick up from what Senior Minister Ramon was saying, there are definitely considerations around illicit activity, around the problems of corruption, around privacy risks that are associated with digital currencies that are at the forefront of the mines and also in low and middle income countries. But I think that this need to be dealt with in the design of the regulatory framework around this rather than be used, not to put that in place. And I think it's important to, and actually, I think it's potential to learn from and build on the use of blockchain guaranteed transactions, such as in the case of Bitcoin. But let me just come to the system that we have now, because low income countries have been really badly affected by global regulation. If you look at regulation concerning fiat currencies, the international standards in banking regulations are often too complex, too difficult, too expensive to enact in these environments. They're unsuitable for low income countries.  Other types of regulations around the Canterra measures, Canterra legislation, particularly in the US, has ended up seeing US banks closing correspondent banking relationships. And so, as a result, we've seen entire countries in the Sahel, in Western Africa, entire economies really seeing restricted banking services for international trade. So we need to have a balance between adopting regulations of digital currencies in the way that we're thinking about in the more advanced economies and tailoring regulations in low and middle income countries in terms of ways practical to implement. But even in advanced economies, I would really urge regulators to think about regulations in a different way. It's important that regulators innovate. They understand that we need new regulatory models in this space that can really be tailored to these new instruments that don't thwart the innovation, that harness the potential, because we've seen an incredible amount of innovation that really will allow us to make the most of the proliferation of digital currencies that we've seen over the past few years. So yes, we need regulations, but we can't have just old banking regulatory models. We need to innovate and keep the end user in mind. Okay. On that note, an interesting one to end on here, the idea of innovation around regulation itself.


So, let us get started again. So, before the break, we left off at the asset properties which transactions must satisfy and it is the job of the database to ensure that these properties are satisfied except for consistency which is the job of the programmer. Now, a transaction can be in different states while it is executing. So, it is active when it is still doing something, the code for the transaction is still running. Now, when the code is finished running, it is done all the updates, reads updates everything that it needed to do. It is said to have partially committed. It succeeded in doing what it wanted to do, but some of the updates which it did may not yet be in a safe place. They may be in memory. So, if the power goes now, the transaction updates will not actually be seen outside. They are lost, but it has finished doing whatever it wanted to do may be in temporary in main memory. On the other hand, it might have failed. If there is a problem during the transaction execution, it cannot continue, then it is said to have failed. So, now from partially committed, what do you have to do? The database system has to make sure that the updates of the transaction are saved on disk and may be backed up elsewhere. And after that has happened, then you say that the transaction is committed. So, from partially committed, the transaction can become committed once the database has taken some extra steps to save all the updates somewhere. On in contrast, once the transaction has failed, the job of the database system is to undo whatever the transaction did. And so, that is called rolling back the transaction. So, the database system will roll back the transaction and restore the database state to its state prior to the start of that transaction. So, whatever updates it did are under. So, the database state is back to where it was with respect to this transaction. Other transactions may have come concurrently. We do not worry about them here. Whatever it saw and updated, you have to undo the updates. So, after this, the transaction is said to have aborted. It is clean. And after it has aborted, well, you have some options depending on, you know, in some cases, you can restart the transaction. It will run now or hopefully will run now. Maybe the failure was simply some transient issue sometime out on something, which hopefully will resolve and if you run it again. In contrast, if there was a logical error in the transaction, you are trying to withdraw money and there is no money, then it has to just quit completely. So, the transaction logic can ask for a rollback and quit completely if it finds there is a problem. But if the transaction logic did not request the rollback, but rather the database system found there was some other issue and rolled it back. In some cases, it might even restart. But typically, that does not happen. So, in any code that you write, you have to be aware that something can go wrong and the transaction can fail in the middle. It is not too common, but it can and does happen. And then, you may have to actually have a piece of code which tries to execute the transaction. If it fails, you may have to retry. If you use Oracle, there is a certain kind of failure, which is due to concurrency control. If that happens, you are supposed to retry the transaction. You are supposed to run it again and hope it works. So, the states of the transaction can be shown in this diagram. Initially, the transaction is active. If something goes wrong, it goes to a failed state. If everything has gone fine and it has finished all the updates, but the updates have not yet been written to disk and so forth. It is partially committed. After that, the database system saves the updates. It goes to committed. At this point, it is still possible for a power failure or something to happen or a disk failure at which point the transaction may go from partially committed to failed and then it may have to be aborted. Now, this aborted state might actually be reached not immediately. If there is a failure, if power goes, what is the state of that transaction? Some updates may have been written to disk. Others have not. So, it is a failed state. It may be partially committed also. But now, if power goes, it is too late for that transaction. If it goes before a certain point, when it is updates are written, then it moves to failed. Now, when power comes back up, the database has to roll back all those incomplete transactions and then those transactions reach an aborted state. In contrast, if all the updates are successfully written out, it reaches a committed state. Once it is committed, you cannot undo it. You cannot roll it back. You can run another transaction, which negates the updates. So, if you transferred money from B to A, you can run a fresh transaction which transfers money from A to B. So, that is a logical sort of thing. But the database cannot simply roll back whatever actions it did after it has committed. Why? Because after it has committed, some other transaction may come and update the same thing. So, now, you cannot just go and easily undo what this did. So, now, all this conceptually is fine, but how do you use it? As a programmer, how on earth do you control what a transaction does? So, the SQL language supports some constructs for handling transactions. So, in SQL, a transaction begins implicitly. You do not say start transaction. As soon as you run a query, a transaction runs. And you can either say commit work to commit the current transaction and begin a new one or roll back work to cost the current transaction to a bot. However, there is a little catch here. Pretty much every database system will do the following. If you run an SQL query or an update, it starts a transaction, runs that SQL query and commits the transaction, assuming it committed successfully. And that is it. That is a transaction as far as SQL is concerned by default. So, if you have five different updates statements in your transaction, what you thought was a logical transaction, the database may turn it into five different transactions as far as the database is concerned. Because by default, every SQL statement is a transaction by itself. That is not what you want. Now, what do you do? So, there are a couple of options. Database systems typically have a control which says, should a SQL statement automatically commit or should you turn autocommit off? So, you can either do it by some configuration in the database or if you use JDBC or other than ODBC, you can say something like this connection dot set autocommit false. So, autocommit means SQL statement commits automatically. Turn it off. It means after it completes, the transaction is not committed. It is still active. So, you can do multiple SQL statements and then issue an SQL statement commit to a core rollback work depending on what you want. So, now it is in your control. Or there are actually some of the constructs which in SQL, which say begin atomic and then do a whole bunch of stuff and then end.  So, that is another language construct that is SQL province begin atomic. Again, not all database is supported, but it is available in the standard. So, as far as the program is concerned, you write a transaction. You run queries. Now, any query which you run might fail. That query itself might give an error. So, then you should be prepared to rollback and quit. In fact, what happens is the transaction, the database, if you turned off autocommit and there is a bunch of things which are part of the same transaction, if something fails, it will implicitly rollback the whole transaction. And then you just exit the database has taken care of rollback. But there may be other errors which you catch. You say there is a problem now. Then I have to rollback or I commit. So, as a programmer, you have to look for error conditions and then either rollback or try some alternative and try to commit. So, you have to be careful about this. What exactly the database does, you have to figure out in case of an SQL error. So, this was the programmer's job. Now, what exactly does the system do? The first part is recovering from failure. This deals with atomicity and durability. Subsequently, we will look at isolation. So, C we are ignoring of acid. So, A and D we are going to look at first. I we are going to look at later. So, as I said, A and D are issues mainly because there are failures. If there were no failures, the system were perfect and you ran one transaction after another, every transaction should complete all its actions unless of course, there is an error condition and it will be durable. But that is not the case. What kind of failures can occur? Well, the first kind of failure is a logical error in a transaction. No money in the account. So, you have to rollback. Another could be a system error. Some kind of deadlock happening inside the system. The only way to resolve it is to rollback one of the transactions. So, that is a simple transaction failure. There may also be a system failure, a power failure or rather hardware or soft operating system fault and so on which causes the entire system to crash or the database component of the system to crash. Maybe not the operating system, but at least the database system. Now, in general, a failure can be arbitrarily bad. Failure could potentially go and erase the whole database. In practice, that does not happen. Most failures do not do such bad things. Why? Because programmers have programmed things carefully by and large. If there is an error, the program stops. It does not continue on and create a mess. Badly designed programs can do that, but database systems are not badly designed. People have put a lot of effort into designing them. Operating systems have been carefully designed and tested. So, generally speaking, an error will not cause any damage to the data. Once in a way, you do here of database bugs which cause data loss. They are very, very rare. So, we will not worry about them. We will assume that the database implementers have taken care of that. So, it does not happen. So, we make the fail stop assumption that non-volatile storage contents are assumed to not be corrupted by a system crash. Now, the database system internally does a variety of things. The only kind of corruption which you cannot prevent at the software level is if the hard disk itself has a problem and the bytes of a file are corrupted. Then, what do you do? You have to at least be able to detect it. So, the hard disk system has some checksums, what are called checksums, to see if the data and the file which you have read is correct. If there is an error in what you have read, the disk system will say, sorry, you cannot read this. The file is corrupted. If the file is corrupted, how do you recover from it? So, if there is a disk failure, you will have to take some other actions to recover. And we would not get into details of that, but it is possible using the same mechanism which we use for durability. So, the recovery subsystem of a database has to deal with failures and ensure atomicity and durability in spite of the failures. And the recovery subsystem of a database, recovery algorithms actually have two parts. One is actions taken during normal transaction processing to ensure that enough information exists to recover from failure. So, while the database is executing normally, some things are written out in the log and some other actions are taken to save some information. Now, if the failure happens, then this saved up information is used to recover from the failure, either to roll back the transaction if it is to be aborted or if the transaction is committed to in effect redo it. If the updates were not quite made to the database, but the information about the updates is available, it can redo the actions so that the database comes back to a state which reflects the completion of the transaction. So, the transactions updates are durable. They are in the database eventually after recovery. Just before recovery, they may not be in the actual place in the database. They may be updates may have been written to some log, but it is not there actually in the proper place in the database. So, during recovery, you may have to look at that log and you meaning the database system has to look at the log and update the actual locations in the database. So, that is what the recovery algorithms do. Now, recovery algorithms have to deal with different kinds of storage. There is volatile storage like main memory which does not survive any system crash. There is non-volatile storage which does survive normal system crash like disk, a flash memory and so forth. However, these can also die in certain circumstances. Disfailures do happen. So, there is a third level of storage called stable storage which is actually a mythical form of storage which survives all failures. As I said, it is not, it is mythical because it cannot actually be implemented. All failures is impossible. However, you can approximate it by maintaining multiple copies on distinct non-volatile media. So, if you have two disks, one here and another in Madras, state bank I think does that. They have a center in Belapur and another in Chennai and any transaction which runs, copy is saved here and over there. So, even if this whole place gets flooded, does not matter. That will be there. The data will be there. So, that is stable storage as far as we are concerned. And if we are not so paranoid, maybe you will just have a RAID system, two disks. So, if you write to both, one of them fails, still the data is there on the other one. That may be good enough. The chance that both will fail is fairly remote. It can happen if the place burns down, but you are willing to take that risk. Then, you can think of that as stable storage. So, now, how do you implement atomicity and durability? Here is a scheme which is actually silly as far as the database is concerned, but is used widely for text editors and others. So, the idea is you have an old copy of the database. Whenever you make any updates, do not make it to the old copy. Write to a completely new copy and after the transaction completes, you will update a point, a dv pointer which is used to point there. After the transaction successfully completes, it is partially committed, you update this pointer to point to the new copy. This new copy should have been flushed to stable storage first. Then you update the pointer. So, that is used by editors. If you use a word or any other emacs, vi, whatever you use, typically they will create a backup file. They will not directly update the file which you want to write to. They will only make all the changes in the backup file. When you say save, some of them will simply copy the thing into the original file. So, there is a danger of corruption if a failure happens during the save, but others will do this. They will keep the old file, rename the old file and then make the pointer point to the new file. I mean the file name. The file name is the same, but the actual file underneath, the file name will be referring instead of the old file, it will refer to the new copy of the file. So, this can be done for file updates of small files. Of course, it is not feasible for large databases. You are not going to copy 100 gigabytes every time. It is silly. It also does not handle concurrent transactions, even if the database is small. If two people want to concurrently make updates, what do you do? This guy has one copy, that guy has one copy. Now, you cannot merge them. So, the point is you have to make updates directly in the shared database. So, what do you do? The answer is using something called log-based recovery. This is the standard which is used all over. The idea is that the updates performed by a transaction are written to a log. All the updates are written to a log. What is written to the log? You will say that you update this part of the database from this value to this value. So, the old value and the new value are both there. Why do you need the old value? To roll it back. Why do you need the new value? To re-do it if required. So, the log contains for every change made to the database, the log will have the old and the new value. So, if the database crashes before the update is performed. So, when you recover, the failure system will look at this log and see if the transaction was committed or about it. So, it looks at each log record. If the transaction was committed eventually, what do you mean by committed? In the context of logs-based recovery, as the transaction performs actions, it writes the old and the new values to the log. It also writes the new value to the database in memory, but that may not yet have been written to disk. It may only be in memory. But the moment it finishes and it has written all the log records for its updates to the log and where is the log sitting? The log is temporarily in memory as the writes are happening, but then it is written to a file on stable storage. So, once all the updates of the transaction, the old and new value for all the updates which have been, they are all written to stable storage, you can say the transaction is committed. Now, the stable storage has enough information. So, even if the database crashes now, when you recover, the log has enough information to redo the transaction. Therefore, you can say it is committed. But if a failure happens before this point where all the records are written, then the transaction cannot be committed. The database has failed. So, you have to roll back the transaction. So, for those which have failed or transactions have failed, you have to undo. So, the log records have old and new. If you undo, you use old value. If you redo, you use the new value. This is the basic idea. And even if there are concurrent transactions, as long as they do not update the same data, if two guys concurrently update the same data, you are in trouble. And that is the job of the concurrency control part of the database system to ensure this does not actually happen. Assuming that does its job, there are a lot of details. I am hiding a lot of details here. Tremendous amount of details are being hidden here. But I just want you to understand that there is a log. You will see the log. If you look at the files in the database, you will see logs in there, a log file depending on the database system. They have different names. There are directory structures for the log. And the log contains these things, the old and new value. And it is used both for rollback and for redo in case of a system failure. Sir. Yeah. Whenever we are committing the transactions, it is writing into the log file. Yes. It is not directly updating the database. It actually updates the database also. But that is in memory. At the same in memory. One can happen immediately after the other. But the update is in memory. There is no guarantee that the update has gone to the disk at this point. But the log is immediately flushed to this. I mean writing into the disk only. When it writes into the disk finally. That is actually up to the database system. So the database system might write to disk immediately. It might actually wait and gather multiple updates to the same page and then write that page to disk. That is up to the database system. The log-based recovery gives it the flexibility. Otherwise, as soon as the update happens and the transaction wants to commit, all of the updates have to be written. Then the overhead is more. I overhead. The log-based recovery lets it get away with not writing it out immediately. Which can improve the speed of the database. Of course, it has to write it out eventually. It cannot postpone writing it indefinitely. So it does get written out. But maybe after a little while. What I understand in spite of this log-based recovery, we cannot ensure 100 percent recoverability. Because these logs are also for some time it is in the memory only. No. For a very short period. Like they define the size up to which like 2 MB or you give switching time so that the log switch happens. No, the log switch is a different. Log switch is a different thing. Log in memory is a different. These are two orthogonal things. So as long as the log records of a transaction have not been written to stable storage, the transaction is still in the partially committed state. The moment that last log record. This is actually a commit log record at the end for that transaction. The moment the commit log record has been written to stable storage, the transaction is partially committed. So this is physically the definition of when a transaction switches from partially committed to committed in a typical database is when that commit log record has reached the log on stable storage, on disk. Will this ensure a 100 percent recoverability? Yes. Yes. So once that log record has gone to stable storage, the transaction's updates will not be lost. They are durable. And after that you inform the application program that commit is successful. Then the application program informs the user that the commit was successful. So this is a normal mode of operation. In certain situations you can speed up the process at a small risk by telling the application it's committed even before this log records written to disk. It is possible to set up the database to do that. That will speed up processing but at a small risk. Some applications do that. They are willing to take that risk. So recovering from failures is one issue. We have seen a very high level view of how recovery happens. There is another issue. If you have a centralized system for all of LIC and it goes down, fine. It will recover. It may take a few minutes to recover. Or if it is not well designed, if the system is not powerful enough, it may take an hour to recover. Or if the power has failed totally in that area, your generator has failed, it may take several hours to recover. Now you cannot shut down all the branches for that long a time. People are waiting to do work to transact with you. So there is a notion of availability which means the database system or whatever system it is should be able to continue processing whatever work it is processing even in the presence of failures. How do you do that? So you have several levels here. The most common kind of failures, power failures, what do you do? Put a UPS. What is the next most common kind of failure? Well, there are system crashes if you use an operating system which is flaky. If you use the newest version of cutting edge version of even Linux, you may get into trouble. So what you do is use something which has been tested for a while. We know it is stable. So you will use an operating system which is stable. You will use hardware which is good. So you minimize the chances of that, but still it can happen. So the next most common sort of thing which we see after taking care of all of this by using good hardware and so forth are disk failures. Especially we have a lot of disk, disk do fail. So what do you do? Well, you use RAID. So a quick summary of RAID. The idea is that, actually here, keep multiple copies of data on separate disks. It looks like a single file to you, but underneath the operating system will keep two copies of the file on two disks. And if one of the disks fails, it is okay. The operating system will detect it is failed. And if you read the file, it will continue to give you data from the other disk. But whenever you write and both the disks are available, it has to write to both. If one has failed and the other is available, when you do a write, it writes to that. Now you have to deal with a failed disk somehow. So usually you have a hardware system which will indicate that this disk has failed. Somebody has to go unplug the disk, put in a new disk. And at that point, the system will copy all the data from one disk to the other. So a disk failure will be pretty much transparent. Yeah, the system will run a bit slower when the disk fails. And when it's copying data again, this system will run a little bit slower. But you don't have to even stop working just because it is failed. In contrast, if your PC disk fails, that's it. Your PC is dead. It's okay. You can, as a developer, you can afford that. But on your central database server, you cannot afford it. You have to use RAID. There are different types of RAID. I've just told you about the simplest kind of RAID, which is called mirroring. There are other kinds, but this is the most common kind. If you want to know more, chapter 11 of the database book has it. Okay, so disk failures can be masked by RAID systems. Network failures, again, there are ways of dealing with transient network failures. But longer term network failures, what do you do? So then the way you interact with the database itself is slightly different. There are what are called persistent messaging systems, where a transaction is sent as a message, like an email message. It's received, it's processed, and then a message is sent back to you. And if the network goes down in between, it's okay. You don't know whether the transaction is completed or not. But eventually when the network comes back up, you can find out. You can ask the database system, did it complete? And if not, well, you do something about it. Okay, so there are techniques to handle network issues like that. So the one thing which you can't really do much about here, with a single system is failure like a flood, fire, long power outage for whatever reason. And that is not uncommon. A couple of years ago, three years ago, I guess, 2005, half of Bombay was under water. Nobody can survive that kind of a thing. Even if you're building a safe, you don't have power, network is down. It cannot be used. I was talking about network failure. With availability, network failure is actually a very important problem. It's a non-trivial problem. So you have a network connection to your data center. If that fiber gets cut, it happens all the time. Somebody does construction, cut, gone. What do you do? The center is cut off. Nobody is able to process transactions. What you do again is have redundancy. You have multiple different fibers coming from different places. So that if one gets cut, the other is still available and can continue working. Maybe it's a little bit slower, but you can continue. So again, as far as possible, you must failures to maximize availability. But if you have a single center, there are something which you cannot mask. Flood, fire, can't help it. So there the solution is to keep a backup at a remote site. And it looks like this conceptually. This is called the primary site where you're doing the transactions. Now, all the updates that you do, including the logs which you write particularly, are shipped over the network to a backup system. If the primary site is gone, then the backup system must now tell the world, hey, the primary is dead. Come talk to me. So what do I mean by the world? Well, there are all these clients sitting here. They should know that they should stop talking to this fellow and start talking to this guy. So there the application logic has to see if it cannot talk to this guy, then it should try the other guy. And the other guy will say, no, I have not yet, I have not taken over yet. This guy is still alive. Maybe you're not able to reach him, but I have not yet taken over. Or he can say the king is dead, long live the king and take over. So now once this guy takes over, it doesn't matter what happened to the primary guy. He's dead, gone, fine. For now, the secondary is active. When the primary comes back up, something has to be done. It has to get all the updates which were done at the secondary, at the backup, copy it back, come back in sync. There is a protocol there, which is non-trivial. And eventually they are back in sync. And at that point, the primary may take over again. And the backup goes back to backup state. So all of this is part of a remote backup setup. And most databases today support remote backup, although there are issues in practice. How do you detect failure? How do you know the primary is dead? Maybe it's just that you are not able to talk to the primary.  So you will need to have multiple communication links. Then you have what is called a heartbeat, some way to keep probing the primary and say, are you alive? Are you alive? Or keep receiving a message saying, I am alive. I am alive. It's called a heartbeat. So all this is part of high availability solutions. They are built in. You don't have to implement any of this. You should just be aware that these things are possible. Once you have a database system in place, high availability options will do all this for you. Sir, when primary is dead, then what about the log records when backup? The log records are sent continuously. As they are written, they are sent to the backup. So the backup has the log records. So it can redo or roll back transactions as required. That's the idea. So then again, there are issues on transfer of control, which I just described. And in particular, to take up control the backup site essentially performs recovery using its copy of the database and the log records. So in effect, it runs the recovery algorithm and comes back in sync. At that point, it can start processing fresh transactions. So there are a couple of different possibilities. One configuration is the backup does nothing normally. It just collects log records. And then when required, it suddenly starts recovery and then takes over. But that can be slow. So there's a hot spare configuration where backup system is actually continually processing log records as they arrive, applying the changes locally. And if the failure is detected, the backup can quickly roll back any incomplete transaction. And within a very short time, literally a few seconds is ready to process new transactions. So that is, the hot spare is commonly used for, I'm sure SBI uses a hot spare, can take over instantly. Now there are other alternatives to remote backup, which are based on replicated data. These generally don't, you know, give very good performance. They're slower. There are transactional issues there. But it's still useful in certain situations where you don't want the cost of remote backup.  And we won't get into that here. So now we'll move on to the last part, which is concurrent transactions. Before we do that, are there any questions on recovery? So in the, yeah, say like the remote backup, we might have a lag of some, say like, say like for single transaction, say like some milliseconds, that, yeah, the last time has not been, say, copied into the log file or has not reached the backup. So in that case, how it will be handled. Okay, that's a good question. So let's say that a transaction was declared committed, the moment its log record reached the local disk, but that log record has not yet reached the remote backup. And now the primary dies. And that log record never reaches the backup. Okay, then you have a problem. You have a transaction which the primary thought is committed, but the backup thought is about it. This can happen. If you want to avoid that, you will declare a transaction committed only after its log record has reached the backup. And the backup acknowledges saying, yeah, I have got it. Then you tell the application program that the transaction is committed. All this configuration has a costing, as you mentioned, in terms of the performance. Yeah, definitely. When a transaction has to commit at two places and synchronization is to be sure. Yes, there's performance, there is management, the human cost involved in managing it, keeping it up, and making sure that your high availability feature doesn't decrease availability. Yeah, if your logs are not going through and the disk gets full, then even though one system is running, it crashes. Okay, so you have to deal with all these kind of Okay, so let's move on now to concurrent execution. So why do we want to allow transactions to run concurrently? Why not let them run one at a time? Most of the transactions, something else, you're not that big, right? You update five records. How long does it take to update five records? You may read five records from this. Each read may involve some time to read it, maybe 10, 20 milliseconds. Then it, so maybe 20 milliseconds times 500 milliseconds. And then it has to write those out. Another 100, 200 milliseconds. So maybe in about 200, 300 milliseconds, your transaction finishes. So why not just run things seriously? Then what is the maximum rate you can get? Maybe you'll get three, four transactions per second, perfectly acceptable at a branch, single branch, or even a divisional thing. Maybe it's okay. It's good enough. But if you have a central thing for all of India, you don't have that flexibility. So what do you do? You have to run things concurrently. And what is the benefit of running them concurrently? The idea is you can have increased processor and disk utilization. So the system has many resources. It has not just one actually, but today multiple CPUs. It has multiple disks. So if a transaction is waiting for a read to happen from disk one, the other disk will be idle. If only one transaction is running, the other CPUs, all the CPUs will be idle. And all the disks except that one disk are going to be idle. So when that finishes, maybe it does some CPU. So now all the disks are idle, and only one CPU is active.  That's bad. So if you can run them concurrently, maybe while this transaction is waiting for a read to complete, another transaction can be using the CPU. A third transaction may be executing a read or write to another disk. So by allowing multiple concurrent transactions, you can actually make full use of the resources and yet have everything run very fast without major problems. But you have to be careful. What if all these transactions go and read or write the same data item? What happens then? There can be a mess. So if you are not careful, we saw an example of a transaction executing and another came in the middle and read inconsistent data. It can get worse. You may be writing some data, another guy can come and overwrite the same data and cause a complete mess.  If you want this benefit and it is worth it, people have spent a huge amount of effort on getting concurrency control right. And that effort is worth it because you get very good response because of that. Another problem is if there's one slow transaction, which takes five minutes, everybody is stuck behind this slow guy. If you run it seriously, that's a major problem. In the olden days, this was more common. You would have reservation systems where it would just hang for no apparent reason. You'd wait in the office for 20 minutes and say, okay, I'll give up or eventually it comes through. That may have been because of things like this. These days, that doesn't happen because they're well designed. So there are a lot of details in chapter 16 if you want to worry about it. But what we are going to do now is give a high level view of what are the issues. We're not going to look at in detail at how to do concurrency control. To understand what are the issues, you should understand what is a schedule. Schedule is a sequence of instructions that specify what the transaction is doing. And it also shows the interaction between transactions. So here is a schedule with two transactions. In this particular schedule, what has happened? This transaction is red A multiplied it by, well, subtracted 10% from A and added it to B and written B back. And then this fellow started and red A removed 50 from A and added 50 to B. So there are two transactions which are both operating on the same A and B. But the schedule shows that this guy ran first, then this guy ran. So what is this vertical line? It's time. This happened first, then this, then this, then this, then this. So that's what a schedule shows, what happened in time. You as a programmer don't have to worry about schedule, but I'm showing this to explain certain concepts which are coming up soon called serializability, which you will see in practice, you will see that word many times. So that is a schedule. So a schedule for a set of transactions consists of all instructions of those transactions. I showed you a schedule for two transactions. And it preserves the order in which instructions appear in each individual transaction. If the two transactions run concurrently, then the schedule can look different. I'll come back to this slide, but just show you an example. Here's an example where T1 did some work, then T2 did some work, then T1 did some more work, then T2 did some more work. This is a schedule where the transactions are mixed. They're running concurrently. I'll come back to this slide in a bit.  And in the schedules which you'll see, we sometimes omit the commit instruction. It's implicit. After the last one, immediately after the last one is a commit. Commit is a request to commit, actually. And we'll assume that that happens immediately. And a transaction that fails to complete will have an abort instruction as the last instruction. So now we saw one schedule. In this schedule, one transaction ran, then the other. This is called a serial schedule. Serial ordering is there, one followed by another, followed by another. So in this serial schedule, this is also serial. Now T1 has run first followed by T2. What is the difference between this and this? Here T1, T2. There, T2 followed by T1. They're both serial schedules, just because I called them 1 and 2 doesn't mean anything. Doesn't mean that one has to run first and then 2. It's just a name. So these are serial schedules. Now from the consistency requirement which we saw, we can say for sure that if a transaction is consistent, take any serial schedule. Initially, the database is consistent. Then after the first transaction completes, the database is consistent. Then the next one starts, then the database is consistent. Everything is fine. So this is good. Serial schedules are good. But of course, they don't perform so well. What about schedule which are not serial? Take this one. It's not serial. These are called concurrent schedules. Now in this particular thing, is it going to lead to disaster, this particular schedule? Some concurrent schedules can lead to disaster. But is this particular one leading to disaster? Actually no. So what happens here is this fellow reads A, finishes writing A. After that, this fellow doesn't touch A. Now this fellow is reading A after this fellow ran. Then this fellow is reading B. This guy didn't touch B yet. This has read B and updated B. Then this has read B. Now if you look from the viewpoint of consistency, you can verify that the sum of A and B is preserved after this schedule, this particular schedule. There are other things where it won't be preserved. But here it is A and plus B will stay the same. The two transactions just move values from A to B. But the sum should be the same and it is in fact in this case. So this schedule intuitively is, in some sense it's okay. It's okay to run things like this. It's safe. But in what sense is it safe? You don't know yet. I have not explained in what sense this is safe and we will see that in a bit. But intuitively, there is something about this schedule which makes it safe. It's okay and we won't allow it to run. There are other schedules which are not safe. Then we won't allow them to run. Just to step ahead of the next few slides. In this case, look at these two parts. If I could move that up and this down. In other words, in this particular schedule, this executed, then this executed. But suppose I flip them. I moved all of this and did it before all of this. Would it make any difference to what each of them writes? This is reading and writing B. This is reading and writing A. So if I did this first, this will not change. So I could conceptually move this up and this of course correspondingly will go down. And that is the serial schedule. Where T1 ran, then T2 ran. So whatever this sees and whatever updates it does are exactly equivalent to the serial schedule where T1 runs, then T2 runs. Therefore, we can say that this schedule is equivalent to that serial schedule. Schedule 1, where T1 ran followed by T2 runs, equivalent in that each statement here reads the same values. Each write writes the same values as that schedule and the final values are all the same as in that schedule. It is equivalent in that sense. So that is just the intuition. It is defined more formally. However, here is a bad schedule. Here we have read A, subtracted A. We have not yet written it. In between this fellow jumps in. It reads the old A. Not the A after the subtracting 50, but the original A. It subtracts 10 percent from A, writes A and then this fellow writes A. So what has happened now? This update is completely lost. The value after this is 50 less than the original A. And then this continues, this continues. You are in trouble. The final value of A is wrong. Very similar. What is the difference between these two schedules? Almost nothing. There are only two small differences. One was write A has come here, read B has come here. Read B causes another problem. There are two problems in this schedule. So we want to allow this schedule, but not this. How do you do this? How do you recognize that this schedule is safe? But this one is not. How do you recognize it? And how do you ensure that only safe schedule is executed? That is the job of the concurrency control component.  As I said before, the C assumption says that each transaction preserves consistency. Therefore, serial execution of transactions preserves consistency. And we will say that a possibly concurrent schedule is serializable if it is equivalent to a serial schedule. What do you mean by equivalent? We will define that formally. There are actually multiple notions of equivalence. We are going to just use one notion called conflict equivalence. So here we say that if a schedule S can be transformed into a schedule S prime by a series of swaps of non-conflicting instructions, we say that S and S prime are conflict equivalent. So if you go back here, we could swap these two, meaning move the read B up ahead of write A. In the given order write A occurs, then read B occurs. But we could flip it. Do read B and then do write A. And the two do not conflict because they are touching completely different data items. There is no conflict. Now if you consider continue with read B versus this statement, there is no conflict. Similarly this and this, there is no conflict. So read B can be moved all the way up to here. Similarly B equal to B plus 50 can move up. Write B can move up. After moving all these things up, we have a serial schedule. So what we found is that schedule S can be transformed into that other schedule by a series of swaps of non-conflicting instructions. And therefore, we will say that this schedule is serializable. It is not serial, it is concurrent, but it is serializable. This word is very important, serializable. You will see this very often. And in particular here, we use the term conflict serializable. People usually omit the word conflict serializable and just say serializable. There are other notions of serializability, and this is the most commonly used notion. So serializability for our purpose will be this, that you can whatever order they executed, it is possible to swap whatever they did with non-conflicting things and come up with a serial order. And therefore, even though they ran concurrently, the final result is consistent. That is important. And it is exactly equivalent to result of some particular serial schedule. What was the serial order? We can figure that out if you wish. But in some sense, it does not matter. It may depend on which was submitted first, which was submitted second. If somebody entered, pressed enter a few seconds later, it could have been the other way. It does not matter. But it is equivalent to some serial order.


Hi guys, Asperger's Grove here, and today's video we are talking about how to tell whether someone has Asperger's So that'll include all of the kind of signs that you can cut up for some of the things that they might say to you But yeah, so funny thing is I have actually recorded this video twice before The first time I had my my mic here not in my hand It was all the way on the desk and the noise gatemate that meant that all the audio was like all choppy and stuff And then the second time I'll probably can set a little clip here I didn't actually plug my mic into the computer, so Just buffoon buffoon actually buffoon So about further ado here are the reason the Without further ado here are some of the ways that you can tell if someone has Asperger's syndrome patting is where someone who has autism or is on the autistic spectrum tries to pass as someone who isn't autistic or a neurotypical which is the kind of Kind of lingo that you can use So basically this is suppressing traits like stimming which is like better movements that Kind of calm us down as well as certain thought patterns that we may have Psychologists generally try to integrate us more into society and while I do think that is a good thing and I am Kind of a little bit against that, but I'll get that one. I'll go into that on another video So this passing we don't do it completely. Well our attempts to Act like we don't have autism usually Don't work very well. So we usually have it can be perceived that we have quite weird quirky traits that Usually you would just kind of accept to something to do with You know, it's just a just a weird quirky funny person, you know, but Although that is a good thing. I think it's a good thing because boring is weird boring is weird witness is not weird So these weird traits can Manifest itself as different mannerisms Maybe different facial expressions when they're talking about something that it's not really related to that facial expression So like they could be like talking about something sad and have like a smiling look on the face or They could be They could actually be quite interested in you romantically or as a friend But they might act like they're not because you know, we don't really tend to know how to How to convey that in certain points of our life, especially when you younger another thing that you couldn't look out for is physical traits So it can be anything from Fidgeting so usually when we're growing up, we have these things called stimming. So my stimming was spinning around in a circle constantly whenever I could and Yeah, so Psychologists and parents and stuff. They obviously it's they kind of want to get rid of that I don't agree of that because I think it's quite helpful But we usually tend to take on things like fidgeting like stuff that there is stimming But maybe not as powerful, but it's more socially acceptable like Just do this really gross thing where I rub my fingers together and like get all the dead skin off. It's it's a bit gross But but yeah, anything like that anything like tapping your feet Spinning having to spin something in your arms. I know there's there's like these fidget spinners now which are actually made for people with learning disabilities and Attention disorders and stuff. So that's kind of the one of the things that you could you could look out for Another thing is looking at their social tendencies. So if they regularly attend Social events or not regularly attend them, but when they attend social events, they might Leave maybe halfway through when everyone's like getting together and stuff or it can manifest itself as When you go into like a restaurant or something they may want to sit in the corner They may want to sit at the far for outside of the circle when you're having a conversation any of those Avoidance behaviors, I don't know if that's a good word to use for it, but there's some things that you can look out for another thing that is actually well documented in Documented in people don't happen there in people who have asperges is Obsessions, so these are special Interests that basically are something that you really in some persons really interested in They may do something called monologuing where they'll talk for ages and ages about a certain subject because they're interested in it Maybe not let you talk which might be quite annoying As well as spending quite a hefty amount of time Look reading around that subject doing stuff To do a bit so for example when I was really obsessed with Yu-Gi-Oh, which is a training card game and also an anime I'd used to watch it all the time whenever I could I'd used to listen to the music from from the show You still listen to like audio books on Yu-Gi-Oh Make decks and stuff during the day and like playing them with my dad at the end of the day These things are That is something that you come account for and it's It's usually like said is something that's not good, but I kind of view them as more of like a passion. So for example my passions now are You know university Taekwondo and exercise to fly that And especially YouTube videos So There's some some things that might be more characterized in people who have autism Referring Referencing something that you do not know about so if they tend to say stuff To do with a certain subject that you might not know about it and like laugh about it and make another reference for it They make kind of kind of like humoring themselves over it So for example if you are talking about I Don't know cars and they they've recently watched a video about cars They'll they'll make like a really vague reference about it and start laughing about it But you'd be left like what were you talking about and you know, that's the kind of quirkiness that you could There's seen in people who have aspergers not everybody everyone's different. We've all got different brains But that is something Stranged or mixed facial expressions. So I have touched on this a little bit in passing, but strange or mixed facial expressions Are a as a result of these social 10 social inbuilt mechanisms that we don't have Or maybe don't have as well developed when we are younger so It takes a lot of focus for us to have a good social conversation So we'd have to think about the facial expressions that we have when we're talking to someone would also have to Think about what we're talking about and listening to them and also filtering out things in the background So it takes a lot of energy to talk to people in general and we usually don't aren't able to multitask That well with it facial expressions and body language and stuff may not be actually telling of how the person what the person Is talking about and how the person is feeling So I said before about them. Maybe talking about something sad and smiling. It can be the opposite It could be talking about something that's really Happy and they could just have a blank face blank face or they may have a monotonous facial expression just in general it tends to dissipate a bit when you get older, but It does still occur sarcasm sarcasm is Really cool Well, I It's a general trait of someone who has autism is Taking everything literally so we filter out these social things these changing tones changing facial expressions changing body language Because we don't particularly Understand them without completely focusing on them. So this sarcasm is Saying something in a certain way with maybe a certain facial expression in a certain scenario It can be quite confusing for someone who has autism. I personally really like sarcasm My dad is probably one of the most sarcastic people out there and it's really funny But I know his mannerisms and I know when he's being sarcastic However, when someone else does it who doesn't usually use sarcasm, I always have to ask Are you being sarcastic even though I can tell there's a little bit of change in their voice? but if they generally are a bit confused when you say something sarcastic or They ask whether you're being serious or not That might be another sign But however, I find it very frustrating because some people they say something sarcastic when they mean it to be partly and True for partly partly not sarcastic as well that really screws in my head So if you do that please stop doing that is really it's really annoying It's not that annoying, but you know exaggeration Being bad at small talk People of autism may not like small talk. I think it's really boring. I can do it and I generally don't like to ask I don't like to do small talk because if I'm not interested in the answer to something I found it very boring I don't want to ask the question But if you want to get to know people in this society you need to ask them kind of thing So you go to someone. Oh, hi. How are you doing? I'm good. Thank you What course at uni do you do and at what year you're in that kind of stuff where where you live in and It may not be very comfortable. We're doing something like that Or may just find it quite boring Another thing is not understanding social concepts So these can be Things like dating friendships family The kind of set things in society that we have and we abide by so like all you you love your family all the time I'm not saying that I don't love my family because I really do I think they're great But I Generally when I was younger I generally Struggled to find the the line between relationships and friendships With people so that would result in me friends owning a lot of people and also the opposite having when I think you know This person is interested me, but they're not I know people in general have difficulty with that, but I Find I think it's something that maybe autistic people may struggle with more So if you find that they're a bit hard to tell what what their motivation is in a certain scenario That might be something to look for but definitely ask them because you know You don't know with someone who has as bad as unless they tell you Because we don't give any social cues or little behind-the-scenes kind of messages. It's Not something that we generally do intelligence or excelling at a One singular or two or three subjects in particular Now this can be due to interest But there is studies that have been put out showing that people with as per just have a higher level intelligence Then the regular person Now it doesn't mean that we're extra extra extra super smart like Einstein level But it does mean that we generally have a high-level intelligence So if they are excelling in a certain subject or they're very interested in a certain subject at school That might be another trait but Also, there's different things in our Language and our way of communicating that you might be able to look for especially when we are younger and One of the things that was shown that is that we may use more and Trying to think of the word See this is what I'm talking about like vibrant dialogue rather than this Yeah, I could have just said conversation or talk or something and so this can be anything from saying You're getting weaker What rather we might say something like it's hindering my performance or something and That might be something to look out for as well as Our accent so I'm from Yorkshire I do have a little bit of Yorkshire my accent and but generally people won't be able to tell whether where I'm from because We usually tend to put on more of a A different kind of accent and I've definitely seen it in some of the people who have as per just It doesn't happen with everybody But that is something that You can look out for if they have some kind of like a little bit more of a posh accent for where they whether from or You know just kind of a weird accent or something. I don't know. Yes Look out for it. You'll be able to know. I mean So nearly about to wrap up the video one of the last things is not being able to concentrate on things When there is a lot of background noise so if you tend to meet up with the person and in parks or in busy bars or Like public or anything like that If you find that after maybe half Sorry about a half an hour If you find that it's had they kind of drift off or like start daydreaming about halfway through the conversation It's hard for us to filter out sensory stimulation. So anything like bright lights noises different touch Sensations and stuff like that. It overrides our ability to concentrate on a single Person so just imagine just all of the The background noise and everything as well as the person's voice melded together It's gonna be hard for us to concentrate We can do this for a certain amount of time, but then again, it drains our energy a lot so we might tend to Our concentration might tend to wane and a certain points So if you find a person that you're talking to Kind of generally doesn't sometimes doesn't seem like they're interested or maybe starts getting anxious or something in public Situations that might be another sign to look out for Okay, so the last thing is One second to last thing is rudeness And as I said before it's hard for us to grasp certain social con concepts and rules We tend to we tend to come across cross may be more rude and polarizing when we're when we're younger Generally because we we don't think as much of how the other person might react to something that we say so I remember when I was when I was younger and with my friends they'd They'd tell me to like swear at one of the The other kids which was like when I was like six or seven or eight or something And I just like straight out just in the middle of scouts not scouts beavers or something like that It was one of those adventure type Clubs and I just called them all bitches just many times in a row because I didn't know what it meant And then when I was told off for it and said that it was a bad word I wouldn't understand because you know why would you it's only a word? Why would you get upset about that? So I'm not saying that you should compromise for someone's rudeness if they're an asshole tell them and Don't kind of Not do anything about it if someone if someone with asperger's Autism has a go at you or says something that might have offended you or something tell them and Obviously if they don't do anything about it, you know There's ditching because they're obviously an asshole, but it might be easier to get to trigger people when you're artistic So just kind of take that into take that into mind when you when you're talking to someone the last thing is the if you were talking to someone and they usually say things like oh I didn't really fit in at school very much or I was bullied a lot at school and Or have bad memories at school. I didn't like school very much There is a higher Rate of bullying with people of asperger's as well as autism in school especially when we're younger the lack of ability in social situations is really like You can really tell this is why it's easier to diagnose someone when they're younger Because these symptoms symptoms don't like that word these qualities are more prevalent in people that age and Therefore they're more like to be bullied because people bully people based on differences in personality and stuff like that Especially when the younger kids So if they have said anything about being bullied or being not understood very well That might be a good sign that they might have other autism Had autism have autism so this has been How to tell whether someone has asperger's or not. I know this has been quite a long video I I made a really good shoot the first time I made this video and which really annoyed makes and it got that right But hopefully this one's kind of okay fingers crossed and So yeah So if you liked the video Make sure to click like to let me know that you like it or click dislike if you didn't like it But I rather you post a comment give me some constricted criticism about how I could better improve the video for next time Also, don't be afraid to post a comment and ask for a certain video request maybe about something that you might be confused about or something that you want me to talk about and Make sure to subscribe if you want to see any more content from me in the future and click the little bell button in the corner I think it's over there So that you get notifications when my stuff goes out. You might want to check out my new social media pages that I've made It's at Asperger's growth for Google plus Facebook and Twitter And if you want to look into my daily life, maybe something that isn't to do with my YouTube channel Make sure to check check out my Instagram account Thomas Henley TKD. That's T H O M A S H A H E N Le y TKD. So thank you very much for watching this video and I hope you guys are having a great day