It's only doing too much at once in parralel that leads to "thrashing".
Sorry to nitpick, but thrashing isn't really what we're talking about here. Thrashing is the state a system gets into when in order to do any useful work more stuff needs to be in memory than will actually fit there, so the system is instead almost constantly waiting for pages to be fetched from swap space.
We're just talking about bad optimisation of disk accesses.
You have a good point, though, and that kind of system could certainly work fairly well.
Other suggestions that come to mind:
- the system might want to try out different start orders on different runs and time things to see what works better, so startups would gradually improve (eg maybe starting a process which does a lot of disk access at the same time as mounting NFS filesystems which uses the network connection is better than doing two disk-intensive startups at once). - Other parameters could be tuned by an automatic feedback process too, like the amount of parallelism. - A kernel option could be provided that gives a process lower priority access to the disk system for the first few seconds of operation, meaning that the higher priority process would effectively have to finish using the disk before the second one would be allowed to. This might or might not require substantial changes; I don't know the Linux disk scheduling code at all, I only know about how such things work in theoretical terms.
What about the value of trade secrets that were disclosed when the network was compromised?
As a small company we have very few, and most of them aren't kept on our computer system. Sure, source code for some of our solutions could be taken, but frankly there's nothing there that a reasonably competent developer couldn't produce in a sane amount of time, and just stealing the source code directly would be a recipe for disaster for most of our competitors. A competitor might also find out what we'd quoted for a few jobs, but on average probably nothing they could use as our expected number of active quotations at any time is probably something like 0.2 or so.
So, essentially, not a lot of value there.
It might be different if the incursion was not detected and the cracker was able to monitor what we did for some time, but that would take an expert in such things to achieve, and the haul just wouldn't be worth it. The best they could hope for would be to install some kind of logger system on a web site that's operated from one of our servers (off site, but a keyboard snoop on the right machine might reveal the passwords) that takes credit card details before passing them on to a secure transaction processor. But that'd only net 1 - 2 card numbers per day, so there are much juicier targets that are, in all honesty, probably a lot easier to hit (eg people who take cards and store them in a database unencrypted, which I know still happens quite a lot). The other sites on the server all process transactions through 3rd parties so never see any credit card numbers at all. They might be able to trick us into sending them some coffee!
Thanks for the references. I hadn't seen any discussion of these previously, and my normal source for virus info only seems to cover win32 viruses.
I think 'malware' is a good term that generally encompasses all such code. The rest have specific meanings, and therefore using them in cases where that specific meaning doesn't apply is probably a bad idea and prone to cause confusion.
cost includes the cost to recover your ENTIRE NETWORK. once one machine is 0wn3D they all are - potentially - and you can't trust anything.
even a small network has a HUGE cost to recover from intrusion.
I wouldn't say that's so. I consider my company's network to be a small network; it has 2 servers and 3 workstations. If it was compromised, our best estimate of downtime is 1 working day. Even if this were to be charged out at the highest rate our company ever works for over all 3 of our employees, the cost would be less than 2,000 GBP (about $3,000 US). This never actually happens in real life. In fact, the actual cost of that downtime to our business is unlikely to exceed 500GBP.
Lost data could be more of a hassle, but due to offline backups that should be mitigated substantially. A restore process might require me to work some overtime to get us back on track for the next working day. I would probably want compensation in the order of 100GBP for that kind of thing. So a maximum cost of 600GBP + a small volume of lost work that can almost certainly be reproduced quite quickly.
their SecureClient VPN client software allows the firewall administrator to [...]
Never trust a client side security solution. Sure, it helps, but reinforce it with added protection on the server side in case somebody subverts it (eg by using a hacked client or a reverse-engineered reimplementation that lack this feature).
SSH allows portforwarding, even backward (i.e. you can run SSH-sessions into the company by contacting an outside server and connecting back over that very ssh-connection.
There's a very simple solution to that.
Put "AllowTcpForwarding no" in/etc/ssh_config
Simple.
(Aside: there is a note in the openssh manual that reads "Note that disabling tcp forwarding does not improve security in any way, as users can always install their own forwarders." I think this only applies if you give them unrestricted shell access. See another post in this thread for information about a restricted shell that allows scp to work but prevents other stuff from executing).
. Close down the ports and keep users from loading spyware or opening email with executable attachments.
The point is, though, there is no way to do this with their home computers. Sure you can do it with a well locked down internal network with all patches applied. Maybe. But you'd better have a damned hot perimiter system to scan for anything unauthorised being downloaded. You'll have to disallow encrypted content, too, and anything that could be a compression format you don't recognise. Or you could run your OS in kiosk mode or something similar, which'll please everyone.
Unfortunately, the history of the space program, aside from an exciting-but-wasteful run like the moon program has been par for the course for the space program.
"Unfortunately, half of the population of the world has a below average income."
This sentence doesn't actually say anything. To paraphrase: the history of the space program [exception that proves the rule] is pretty much what we have to come expect, given the history of the space program.
Increased productivity does not inherently increase wages. In a free market, wages will decline as productivity improves, because the labor pool will become bigger as more people are unemployed. Total buying power doesn't increase unless wages do, so there isn't inherently a market for more stuff. An economy with a big pool of permanently unemployed or underemployed people dragging wages down is economically stable. Most of the third world is stuck in that mode. THe US is headed there.
OK, I'm gonna bite on that one.
This just isn't true. It might work for a closed system (ie the whole world, or a country that does not trade externally) but if you're talking about an individual country in the real world, increased productivity results in more production, more production results in more exports and more exports result in a better trade deficit, which allows for higher wages in real terms (whereas your example gives lower wages but also deflation as the market stagnates, resulting in actual average spending power being roughly equal). The only way to improve wealth in the long term is to increase the value of (exports - imports)/capita. The key method here is to increase productivity (other techniques are to become market leaders and build reputation in a field, this is a technique employed well by numerous far eastern countries, particularly taiwan).
I remember seeing stuff about a specifically designed emergency reentry vehicle, basically a lifting body type glider that could carry 2 crew, and I think there were supposed to be two of them. I take it that was never implemented?
Also, unless you are short on memory, your kde/twm compile shouldn't have much, if any difference. Compiling the kernel is mainly a IO bound or CPU bound, memory isn't really used that much by the compiler.
That's what I thought at first, but there is a lot of I/O going on, and a lot of it is repetitive (loading include files, compiler support files, stuff like that) and can benefit from a large disk cache. Don't know how much it uses, but would be unsurprised if it couldn't benefit from at least 50 or so Mb. So on a 128Mb machine (not uncommon still) your desktop environment could start hurting it, and on a 64Mb machine it almost certainly does.
Why the hell are you running a WM at all on a Server? Your workstation, OK I can see that (I wouldn't live without my WM of choice on my workstation), but on a Server?
I have run WMs on my server. I occasionally use Xvnc to access the server's desktop to run config utilities, etc, and at that point in time you kind of need a window manager (OK, I could just run Xvnc and put apps directly onto it, but it wouldn't exactly be pleasant...).
Movie theaters ask their customers not to talk during the movie so they won't annoy the other customers. And will kick you out if you don't comply. That's never been considered an infringement on free speech.
IANAL (IAEA [I ain't even American]), but the constitution only specifies that the government can't pass laws that restrict free speech. It says nothing about private individuals/corporations making such rules and enforcing them in any way they see fit.
The essential idea of simplification to this point of view is that you ensure that everything will work before making any changes. So in your example, you would check for all the possible error conditions that would prevent the inventory update from succeeding before authorising the card.
However, this doesn't really fit in with the entire model used because one requirement is that all state information modified by a transaction must be stored within the same system, otherwise replaying the transactions to recover from an error will not work correctly (i.e. the customer would be charged twice!).
I'll agree, its not suitable for all purposes. And if you need to span data that's stored in two separate locations, well tough luck really. But for many other purposes, its fine (i.e., if you really wanted to, the credit card authorisation system could work using this scheme).
(BTW: with a traditional PDQ style credit card authorization, this is a non-issue. The authorization is just a check that the transaction won't be bounced, but doesn't change any data. The data is only updated when the signed paper is submitted. So this system actually can be used in the described situation in reality.) (Yes, I have noticed the irony in the fact that I've just described the fact that credit card authorisation effectively uses a 2 phase commit system).
Does this imply that, for example, Linux MP3 encoders are now legal in the EU, without royalty or authorization [or will be]?
My interpetation is: yes, but only if you can demonstrate a necessity to do it in order to enable some non-infringing activity. If another data format will allow the same activity to occur, then you should use that data format instead. But if, say, you have a dumb hardware device that'll only play MP3s, then yes you could encode MP3s and be done with it.
1. There is no such thing as contributory patent infringement, I believe. 2. You are guaranteed the right to describe how a patented technology works. In fact, it must be adequately described in the patent claims for someone knowledgeable in the field to implement it. And patent claims are (I understand) freely republishable, as they are a matter of public record. 3. Providing somebody with (eg) software which violates a patent is not (necessarily) an offence, as they are permitted to use the patented technique for personal experimentation purposes.
So, no, I don't think this can be used to close websites and stifle free speech.
I think you've probably missed the more relevant parts of their site. It is a bit of a mess.
Prevayler isn't a database server. Its an object storage library. So its not a matter of a client not wanting to run it; you link it to your own app and manage your own data with it. The only reason a client couldn't run it would be (a) no support for Java (unlikely) or (b) not enough RAM (which is the big problem).
Prevayler stores all of your objects in RAM while you're working on them, and at the same time maintains an (apparently) reliable disk backup. To do this, it uses the standard Java object serialization API. To maintain consistency, it requires you to perform all updates through serializable command objects. So you end up with two files; one is a snapshot of all the objects in your store at some point in time, the other is a log of all the commands executed since that point in time.
The code is, apparently, only 335 lines long. It is very easy to understand. There can be no vendor lockin because of this simplicity. I looked at the version 1 code about a year ago and probably remember enough about it that I could write a program to load in the stored objects.
The "organising data in a more optimal fashion" is probably simply a reference to the fact that you can use it with any serialisable Java objects, so you can have references between objects that don't need index lookups, use most of the standard Java classes to organise your data (so you're not constrained to tree indices, you can use hashtables or arrays or whatever you think most appropriate), stuff like that. Basically, because it does less for you, you have more choice.
While I have to agree with some of the things you're saying (like RDBMSs are the way to go for most real world applications), I have to disagree with some things you've said:
They claim there's no need for two-phase commit (2pc), as though the only systems they need to interact with are (or will be) prevaylor.
The design decision they've made regarding transaction implementation is kind of orthogonal to their storage decision, although it is a design that works better in memory than it does on disk.
But, rather than 'begin transaction, update some stuff, check some stuff, if its all ok commit', they do 'prevent any updates that would change the outcome of the precondition; evaluate precondition; if its true, do the updates; allow other transactions to be processed'. Mathematically speaking, these two are equivalent[*], although the latter way is a more difficult way of thinking about the problem that will slow development down.
The whole "let's keep it in RAM" is cute, and for a lot of projects is probably all you need, but for any kind of large data set you just can't buy enough RAM to hold it all. Once it goes to disk, there's a whole new set of problems.
The only real problems I can see are 'how do we reliably store this on disk, how do we load it back transparently'. Admittedly, that's a big problem, but its not one that hasn't been addressed before.
[*]: I can't prove this. It just feels like they must be.
You're probably not too far from the truth. Quote from the site:
The current production release implementation code is 335 lines long
I think I could write a bug free 335 line long program over the course of 18 months, which is I think roughly how long this has been in development for. That's less than 1 LOC per day! You were probably writing that example about 3000 times faster than they were writing prevayler!;-)
How does "the programmer end up coding all the communications layer himself" if RMI is used as a communications layer?
We are discussing how this Java "database" library could distribute transactions across a network and still maintain integrity. You need two phase commit for such transactions
Or you need to simplify the transactions to the point that you specify a single command, which includes an implicit decision on whether or not to commit. That is, all the logic of the transaction must be known to the server before it begins executing.
This is equivalent to sending a message to the server that says something like "if record x hasn't been updated since time t, change record y by setting field f to the result of expression e". There is no need for a two phase commit if you express all of your transactions with this kind of logic. Integrity is still maintained.
Slashdot Mirror
Siemens is the european equivalent for mho
:-)
Huh? Siemens are SI (that is, international standard) units, there's nothing European about them other than their name
I'd never heard of 'mhos' before today, although having looked it up in a suitable reference it is defined as an 'archaic' term for siemens...
It's only doing too much at once in parralel that leads to "thrashing".
Sorry to nitpick, but thrashing isn't really what we're talking about here. Thrashing is the state a system gets into when in order to do any useful work more stuff needs to be in memory than will actually fit there, so the system is instead almost constantly waiting for pages to be fetched from swap space.
We're just talking about bad optimisation of disk accesses.
You have a good point, though, and that kind of system could certainly work fairly well.
Other suggestions that come to mind:
- the system might want to try out different start orders on different runs and time things to see what works better, so startups would gradually improve (eg maybe starting a process which does a lot of disk access at the same time as mounting NFS filesystems which uses the network connection is better than doing two disk-intensive startups at once).
- Other parameters could be tuned by an automatic feedback process too, like the amount of parallelism.
- A kernel option could be provided that gives a process lower priority access to the disk system for the first few seconds of operation, meaning that the higher priority process would effectively have to finish using the disk before the second one would be allowed to. This might or might not require substantial changes; I don't know the Linux disk scheduling code at all, I only know about how such things work in theoretical terms.
What about the value of trade secrets that were disclosed when the network was compromised?
As a small company we have very few, and most of them aren't kept on our computer system. Sure, source code for some of our solutions could be taken, but frankly there's nothing there that a reasonably competent developer couldn't produce in a sane amount of time, and just stealing the source code directly would be a recipe for disaster for most of our competitors. A competitor might also find out what we'd quoted for a few jobs, but on average probably nothing they could use as our expected number of active quotations at any time is probably something like 0.2 or so.
So, essentially, not a lot of value there.
It might be different if the incursion was not detected and the cracker was able to monitor what we did for some time, but that would take an expert in such things to achieve, and the haul just wouldn't be worth it. The best they could hope for would be to install some kind of logger system on a web site that's operated from one of our servers (off site, but a keyboard snoop on the right machine might reveal the passwords) that takes credit card details before passing them on to a secure transaction processor. But that'd only net 1 - 2 card numbers per day, so there are much juicier targets that are, in all honesty, probably a lot easier to hit (eg people who take cards and store them in a database unencrypted, which I know still happens quite a lot). The other sites on the server all process transactions through 3rd parties so never see any credit card numbers at all. They might be able to trick us into sending them some coffee!
Thanks for the references. I hadn't seen any discussion of these previously, and my normal source for virus info only seems to cover win32 viruses.
:-)
I think 'malware' is a good term that generally encompasses all such code. The rest have specific meanings, and therefore using them in cases where that specific meaning doesn't apply is probably a bad idea and prone to cause confusion.
Personally, I blame "good times" for it all.
cost includes the cost to recover your ENTIRE NETWORK. once one machine is 0wn3D they all are - potentially - and you can't trust anything.
even a small network has a HUGE cost to recover from intrusion.
I wouldn't say that's so. I consider my company's network to be a small network; it has 2 servers and 3 workstations. If it was compromised, our best estimate of downtime is 1 working day. Even if this were to be charged out at the highest rate our company ever works for over all 3 of our employees, the cost would be less than 2,000 GBP (about $3,000 US). This never actually happens in real life. In fact, the actual cost of that downtime to our business is unlikely to exceed 500GBP.
Lost data could be more of a hassle, but due to offline backups that should be mitigated substantially. A restore process might require me to work some overtime to get us back on track for the next working day. I would probably want compensation in the order of 100GBP for that kind of thing. So a maximum cost of 600GBP + a small volume of lost work that can almost certainly be reproduced quite quickly.
their SecureClient VPN client software allows the firewall administrator to [...]
Never trust a client side security solution. Sure, it helps, but reinforce it with added protection on the server side in case somebody subverts it (eg by using a hacked client or a reverse-engineered reimplementation that lack this feature).
Actually, I'm not aware of any in-the-wild viruses for Linux. If you know of any please let me know.
There are a few worms, I know (eg this one).
(OK, so I'm getting fed up of people who should know better not distinguishing between viruses and worms).
SSH allows portforwarding, even backward (i.e. you can run SSH-sessions into the company by contacting an outside server and connecting back over that very ssh-connection.
/etc/ssh_config
There's a very simple solution to that.
Put "AllowTcpForwarding no" in
Simple.
(Aside: there is a note in the openssh manual that reads "Note that disabling tcp forwarding does not improve security in any way, as users can always install their own forwarders." I think this only applies if you give them unrestricted shell access. See another post in this thread for information about a restricted shell that allows scp to work but prevents other stuff from executing).
. Close down the ports and keep users from loading spyware or opening email with executable attachments.
The point is, though, there is no way to do this with their home computers. Sure you can do it with a well locked down internal network with all patches applied. Maybe. But you'd better have a damned hot perimiter system to scan for anything unauthorised being downloaded. You'll have to disallow encrypted content, too, and anything that could be a compression format you don't recognise. Or you could run your OS in kiosk mode or something similar, which'll please everyone.
Unfortunately, the history of the space program, aside from an exciting-but-wasteful run like the moon program has been par for the course for the space program.
:-)
"Unfortunately, half of the population of the world has a below average income."
This sentence doesn't actually say anything. To paraphrase: the history of the space program [exception that proves the rule] is pretty much what we have to come expect, given the history of the space program.
You see the problem?
Increased productivity does not inherently increase wages. In a free market, wages will decline as productivity improves, because the labor pool will become bigger as more people are unemployed. Total buying power doesn't increase unless wages do, so there isn't inherently a market for more stuff. An economy with a big pool of permanently unemployed or underemployed people dragging wages down is economically stable. Most of the third world is stuck in that mode. THe US is headed there.
OK, I'm gonna bite on that one.
This just isn't true. It might work for a closed system (ie the whole world, or a country that does not trade externally) but if you're talking about an individual country in the real world, increased productivity results in more production, more production results in more exports and more exports result in a better trade deficit, which allows for higher wages in real terms (whereas your example gives lower wages but also deflation as the market stagnates, resulting in actual average spending power being roughly equal). The only way to improve wealth in the long term is to increase the value of (exports - imports)/capita. The key method here is to increase productivity (other techniques are to become market leaders and build reputation in a field, this is a technique employed well by numerous far eastern countries, particularly taiwan).
I remember seeing stuff about a specifically designed emergency reentry vehicle, basically a lifting body type glider that could carry 2 crew, and I think there were supposed to be two of them. I take it that was never implemented?
Also, unless you are short on memory, your kde/twm compile shouldn't have much, if any difference. Compiling the kernel is mainly a IO bound or CPU bound, memory isn't really used that much by the compiler.
That's what I thought at first, but there is a lot of I/O going on, and a lot of it is repetitive (loading include files, compiler support files, stuff like that) and can benefit from a large disk cache. Don't know how much it uses, but would be unsurprised if it couldn't benefit from at least 50 or so Mb. So on a 128Mb machine (not uncommon still) your desktop environment could start hurting it, and on a 64Mb machine it almost certainly does.
Not a huge amount, though.
Why the hell are you running a WM at all on a Server? Your workstation, OK I can see that (I wouldn't live without my WM of choice on my workstation), but on a Server?
I have run WMs on my server. I occasionally use Xvnc to access the server's desktop to run config utilities, etc, and at that point in time you kind of need a window manager (OK, I could just run Xvnc and put apps directly onto it, but it wouldn't exactly be pleasant...).
*LOL*
Didn't know google had an automatic marketing slogan generator before.
English Colombia, the sufficient university
Movie theaters ask their customers not to talk during the movie so they won't annoy the other customers. And will kick you out if you don't comply. That's never been considered an infringement on free speech.
IANAL (IAEA [I ain't even American]), but the constitution only specifies that the government can't pass laws that restrict free speech. It says nothing about private individuals/corporations making such rules and enforcing them in any way they see fit.
Yep, that's the nail, and that there is its head.
The essential idea of simplification to this point of view is that you ensure that everything will work before making any changes. So in your example, you would check for all the possible error conditions that would prevent the inventory update from succeeding before authorising the card.
However, this doesn't really fit in with the entire model used because one requirement is that all state information modified by a transaction must be stored within the same system, otherwise replaying the transactions to recover from an error will not work correctly (i.e. the customer would be charged twice!).
I'll agree, its not suitable for all purposes. And if you need to span data that's stored in two separate locations, well tough luck really. But for many other purposes, its fine (i.e., if you really wanted to, the credit card authorisation system could work using this scheme).
(BTW: with a traditional PDQ style credit card authorization, this is a non-issue. The authorization is just a check that the transaction won't be bounced, but doesn't change any data. The data is only updated when the signed paper is submitted. So this system actually can be used in the described situation in reality.) (Yes, I have noticed the irony in the fact that I've just described the fact that credit card authorisation effectively uses a 2 phase commit system).
OK, I know I said I wasn't going to rise to it, but I just can't resist this...
lusers use applications, that's the difference.
And I suppose you never use an application?
Does this imply that, for example, Linux MP3 encoders are now legal in the EU, without royalty or authorization [or will be]?
My interpetation is: yes, but only if you can demonstrate a necessity to do it in order to enable some non-infringing activity. If another data format will allow the same activity to occur, then you should use that data format instead. But if, say, you have a dumb hardware device that'll only play MP3s, then yes you could encode MP3s and be done with it.
But check that with a patent lawyer first...
Er, yeah, right. This is nothing like the DMCA.
1. There is no such thing as contributory patent infringement, I believe.
2. You are guaranteed the right to describe how a patented technology works. In fact, it must be adequately described in the patent claims for someone knowledgeable in the field to implement it. And patent claims are (I understand) freely republishable, as they are a matter of public record.
3. Providing somebody with (eg) software which violates a patent is not (necessarily) an offence, as they are permitted to use the patented technique for personal experimentation purposes.
So, no, I don't think this can be used to close websites and stifle free speech.
I think you've probably missed the more relevant parts of their site. It is a bit of a mess.
Prevayler isn't a database server. Its an object storage library. So its not a matter of a client not wanting to run it; you link it to your own app and manage your own data with it. The only reason a client couldn't run it would be (a) no support for Java (unlikely) or (b) not enough RAM (which is the big problem).
Prevayler stores all of your objects in RAM while you're working on them, and at the same time maintains an (apparently) reliable disk backup. To do this, it uses the standard Java object serialization API. To maintain consistency, it requires you to perform all updates through serializable command objects. So you end up with two files; one is a snapshot of all the objects in your store at some point in time, the other is a log of all the commands executed since that point in time.
The code is, apparently, only 335 lines long. It is very easy to understand. There can be no vendor lockin because of this simplicity. I looked at the version 1 code about a year ago and probably remember enough about it that I could write a program to load in the stored objects.
The "organising data in a more optimal fashion" is probably simply a reference to the fact that you can use it with any serialisable Java objects, so you can have references between objects that don't need index lookups, use most of the standard Java classes to organise your data (so you're not constrained to tree indices, you can use hashtables or arrays or whatever you think most appropriate), stuff like that. Basically, because it does less for you, you have more choice.
While I have to agree with some of the things you're saying (like RDBMSs are the way to go for most real world applications), I have to disagree with some things you've said:
They claim there's no need for two-phase commit (2pc), as though the only systems they need to interact with are (or will be) prevaylor.
The design decision they've made regarding transaction implementation is kind of orthogonal to their storage decision, although it is a design that works better in memory than it does on disk.
But, rather than 'begin transaction, update some stuff, check some stuff, if its all ok commit', they do 'prevent any updates that would change the outcome of the precondition; evaluate precondition; if its true, do the updates; allow other transactions to be processed'. Mathematically speaking, these two are equivalent[*], although the latter way is a more difficult way of thinking about the problem that will slow development down.
The whole "let's keep it in RAM" is cute, and for a lot of projects is probably all you need, but for any kind of large data set you just can't buy enough RAM to hold it all. Once it goes to disk, there's a whole new set of problems.
The only real problems I can see are 'how do we reliably store this on disk, how do we load it back transparently'. Admittedly, that's a big problem, but its not one that hasn't been addressed before.
[*]: I can't prove this. It just feels like they must be.
You're probably not too far from the truth. Quote from the site:
;-)
The current production release implementation code is 335 lines long
I think I could write a bug free 335 line long program over the course of 18 months, which is I think roughly how long this has been in development for. That's less than 1 LOC per day! You were probably writing that example about 3000 times faster than they were writing prevayler!
How does "the programmer end up coding all the communications layer himself" if RMI is used as a communications layer?
We are discussing how this Java "database" library could distribute transactions across a network and still maintain integrity. You need two phase commit for such transactions
Or you need to simplify the transactions to the point that you specify a single command, which includes an implicit decision on whether or not to commit. That is, all the logic of the transaction must be known to the server before it begins executing.
This is equivalent to sending a message to the server that says something like "if record x hasn't been updated since time t, change record y by setting field f to the result of expression e". There is no need for a two phase commit if you express all of your transactions with this kind of logic. Integrity is still maintained.