Definition of DATA LOSS (changed from roll back)

Androconium · May 2019

When people say "roll back" is this describing a situation where:

you get disconnected
after logging in again, you are at an earlier point in your game play than you were when you got disconnected?

If so, then why is this situation not being described for what it is? i.e. DATA LOSS.

Cpt_Teemo · May 2019

I can't even login to SI on most of my chars right now i don't know lol

Merlight · May 2019

https://en.wikipedia.org/wiki/Rollback_(data_management)

In database technologies, a rollback is an operation which returns the database to some previous state.

Androconium · May 2019

Merlight wrote: »

https://en.wikipedia.org/wiki/Rollback_(data_management)

In database technologies, a rollback is an operation which returns the database to some previous state.

Yes. I've actually done it.
It's used to remove an upgrade that has failed.

An operation is planned. What is happening here is unplanned.
This symptoms so far suggest that nothing is being "rolled back", simply because it hasn't been captured in the first place.

This is why I asked the question...

The current situation is not a planned Roll Back operation; it is simply data loss.

Master_Kas · May 2019

I just finished a entire zones skyshards & lorebooks, get logged out + rollback and have to do it all again... xD

therift · May 2019

Server has Alzheimer's

Merlight · May 2019

Androconium wrote: »

The current situation is not a planned Roll Back operation; it is simply data loss.

What's your point? Every rollback is data lost.

Carl-lan · May 2019

OP I think people are just used to calling it rollback. Weather it’s technically correct or not doesn’t really matter as people know what they mean in this case. I wouldn’t worry about correcting people. It’s important ZIS knows there’s an issue though.

mcagatayg · May 2019

I've been getting kicked to login screen and when i log in to my character i lose data around 10 or so mins back... really frustrating

rotaugen454 · May 2019

Master_Kas wrote: »

I just finished a entire zones skyshards & lorebooks, get logged out + rollback and have to do it all again... xD

Great way to sell Crown Store skyshards...

😜

notyuu · May 2019

Speaking of rollback

@ZOS_GinaBruno
are you and your cohorts aware of the server rollback issue happening on pc-eu?

Sindarin · May 2019

Stonefalls ... I cant get to the prophet (even get close to mark it on the map. after couple steps I am kicking back to character selection windows and then I'm in location before Stonefalls

zaria · May 2019

Androconium wrote: »

When people say "roll back" is this describing a situation where:
you get disconnected

after logging in again, you are at an earlier point in your game play than you were when you got disconnected?

If so, then why is this situation not being described for what it is? i.e. DATA LOSS.

More probably error in game status. In overland you can probably play for quite some time before getting out of sync.
So you do quests and kill stuff, perhaps in an solo instance, so you are playing an solo game, however servers need to verify loot or some cheaters will get purple briarheart jewelry on any drop.

ZonasArch · May 2019

Androconium wrote: »

When people say "roll back" is this describing a situation where:
you get disconnected

after logging in again, you are at an earlier point in your game play than you were when you got disconnected?

If so, then why is this situation not being described for what it is? i.e. DATA LOSS.

If DCd, it's not data loss. It's a DC.

richo262 · May 2019

PC NA too

Vandril · May 2019

Androconium wrote: »

Merlight wrote: »

https://en.wikipedia.org/wiki/Rollback_(data_management)

In database technologies, a rollback is an operation which returns the database to some previous state.

Yes. I've actually done it.
It's used to remove an upgrade that has failed.

An operation is planned. What is happening here is unplanned.
This symptoms so far suggest that nothing is being "rolled back", simply because it hasn't been captured in the first place.

This is why I asked the question...

The current situation is not a planned Roll Back operation; it is simply data loss.

A few things I guess I could help clear up.

First, an operation doesn't need to be planned. It's not always an operation as in the sense that it is a planned course of action, but can be an operation in the sense of something is operating i.e. something is in effect. In the case of a rollback, the database is what's operating, and in a very specific manner - in a way that "rolls back" data in the database to what the data used to be in the past.

Second, despite how operations don't necessarily need to be planned, a rollback operation actually is planned. All rollback operations are planned. The function that is a rollback - that the data in a database will be set to what it used to be in the past through some specific method of achieving such - is planned in that it must have been programmed to function the way it does at some point. Dynamic rollbacks in the case of critical errors are still planned, because the rollbacks are setup to occur on the condition of the occurrence of a critical error. In other words, both the actual operation of a rollback itself and the condition in which a dynamic rollback will happen are determined at the time of development, thus meaning they are planned. What isn't planned is the literal time when a dynamic rollback will have to take place, since it's impossible to know when critical errors will arise and the conditions for starting the rollback will be met.

To clarify, a rollback is data loss, but it's a very specific type of data loss. The term rollback carries the implications that the data loss was intentional due to circumstances, controlled in how data was lost, and controlled in the scope of data that was lost. Just saying "data loss" doesn't give enough detail as to what actually happened because it lacks these implications. So, the term rollback is used instead of data loss because it better explains exactly what happened.

Also, rollbacks are used for a heck of a lot more than failed updates. It's most commonly used for data corruption, of which failed updates is only one of many causes.

Androconium · May 2019

To answer several other questions, this:

Master_Kas wrote: »

I just finished a entire zones skyshards & lorebooks, get logged out + rollback and have to do it all again... xD

is not roll back. No process has been initiated.
What has happened is that ESO has stopped saving your game as it normally does.

So when you are disconnected, you restore from the last good save-point and you lose data AND progress; from the good save-point forward to the point where you were disconnected.
Whatever random 'wins' that you might have had with RNG are gone also.

Given the way that ESO has successfully managed this issue in the past (transaction logging or something similar) to see so many players complaining about this suggests an imminent failure.

Game-play in ESO is real-time.

Whatever you believe an MMO should do, real-time game-play data loss in totally and utterly unacceptable.

Androconium · May 2019

Merlight wrote: »

Androconium wrote: »

The current situation is not a planned Roll Back operation; it is simply data loss.

What's your point? Every rollback is data lost.

My point is that what you are seeing is not a planned rollback of data. By definition, rollback is a planned process. A decision is actively made to restore a previous software image to mitigate some problem with the current image.

As the disconnection results in data loss, the cause of the problem here is completely different.

I'm not having a go at you, but the loss of live data in any situation is way more serious.

Androconium · May 2019

Vandril wrote: »

Androconium wrote: »

Merlight wrote: »

https://en.wikipedia.org/wiki/Rollback_(data_management)

In database technologies, a rollback is an operation which returns the database to some previous state.

Yes. I've actually done it.
It's used to remove an upgrade that has failed.

An operation is planned. What is happening here is unplanned.
This symptoms so far suggest that nothing is being "rolled back", simply because it hasn't been captured in the first place.

This is why I asked the question...

The current situation is not a planned Roll Back operation; it is simply data loss.

A few things I guess I could help clear up.

First, an operation doesn't need to be planned. It's not always an operation as in the sense that it is a planned course of action, but can be an operation in the sense of something is operating i.e. something is in effect. In the case of a rollback, the database is what's operating, and in a very specific manner - in a way that "rolls back" data in the database to what the data used to be in the past.

Second, despite how operations don't necessarily need to be planned, a rollback operation actually is planned. All rollback operations are planned. The function that is a rollback - that the data in a database will be set to what it used to be in the past through some specific method of achieving such - is planned in that it must have been programmed to function the way it does at some point. Dynamic rollbacks in the case of critical errors are still planned, because the rollbacks are setup to occur on the condition of the occurrence of a critical error. In other words, both the actual operation of a rollback itself and the condition in which a dynamic rollback will happen are determined at the time of development, thus meaning they are planned. What isn't planned is the literal time when a dynamic rollback will have to take place, since it's impossible to know when critical errors will arise and the conditions for starting the rollback will be met.

To clarify, a rollback is data loss, but it's a very specific type of data loss. The term rollback carries the implications that the data loss was intentional due to circumstances, controlled in how data was lost, and controlled in the scope of data that was lost. Just saying "data loss" doesn't give enough detail as to what actually happened because it lacks these implications. So, the term rollback is used instead of data loss because it better explains exactly what happened.

Also, rollbacks are used for a heck of a lot more than failed updates. It's most commonly used for data corruption, of which failed updates is only one of many causes.

Controlled data loss?

I'm not disputing any of your comments, but I'm also not convinced that 'controlled data loss' is something that would acceptable in the banking industry.

The root cause of the problem here is the disconnects.

It may be that the last valid save point is the actual time of the disconnect from the server; and the client software continues to function. I don't know enough about that.

Vandril · May 2019

Androconium wrote: »

Vandril wrote: »

Androconium wrote: »

Merlight wrote: »

https://en.wikipedia.org/wiki/Rollback_(data_management)

In database technologies, a rollback is an operation which returns the database to some previous state.

Yes. I've actually done it.
It's used to remove an upgrade that has failed.

An operation is planned. What is happening here is unplanned.
This symptoms so far suggest that nothing is being "rolled back", simply because it hasn't been captured in the first place.

This is why I asked the question...

The current situation is not a planned Roll Back operation; it is simply data loss.

A few things I guess I could help clear up.

First, an operation doesn't need to be planned. It's not always an operation as in the sense that it is a planned course of action, but can be an operation in the sense of something is operating i.e. something is in effect. In the case of a rollback, the database is what's operating, and in a very specific manner - in a way that "rolls back" data in the database to what the data used to be in the past.

Second, despite how operations don't necessarily need to be planned, a rollback operation actually is planned. All rollback operations are planned. The function that is a rollback - that the data in a database will be set to what it used to be in the past through some specific method of achieving such - is planned in that it must have been programmed to function the way it does at some point. Dynamic rollbacks in the case of critical errors are still planned, because the rollbacks are setup to occur on the condition of the occurrence of a critical error. In other words, both the actual operation of a rollback itself and the condition in which a dynamic rollback will happen are determined at the time of development, thus meaning they are planned. What isn't planned is the literal time when a dynamic rollback will have to take place, since it's impossible to know when critical errors will arise and the conditions for starting the rollback will be met.

To clarify, a rollback is data loss, but it's a very specific type of data loss. The term rollback carries the implications that the data loss was intentional due to circumstances, controlled in how data was lost, and controlled in the scope of data that was lost. Just saying "data loss" doesn't give enough detail as to what actually happened because it lacks these implications. So, the term rollback is used instead of data loss because it better explains exactly what happened.

Also, rollbacks are used for a heck of a lot more than failed updates. It's most commonly used for data corruption, of which failed updates is only one of many causes.

Controlled data loss?

I'm not disputing any of your comments, but I'm also not convinced that 'controlled data loss' is something that would acceptable in the banking industry.

You're certainly not wrong on that, but what's considered acceptable or not has absolutely no effect on how the technology functions or the reason behind why certain bits of terminology are used as they are. I'm sure the banking industry uses more thorough, less data-destructive, and far more expensive measures to ensure data integrity than ESO ever will. Probably through absolutely ludicrous amounts of redundancy, if I had to hazard a guess.

Your question was why they're calling it a rollback in ESO instead of just data loss, right? That, primarily, was what I was trying to answer. I had no intention of disputing whether or not the amount of data loss ESO experiences during these character-localized rollbacks is acceptable.

Androconium wrote: »

Vandril wrote: »

Androconium wrote: »

Merlight wrote: »

https://en.wikipedia.org/wiki/Rollback_(data_management)

In database technologies, a rollback is an operation which returns the database to some previous state.

Yes. I've actually done it.
It's used to remove an upgrade that has failed.

An operation is planned. What is happening here is unplanned.
This symptoms so far suggest that nothing is being "rolled back", simply because it hasn't been captured in the first place.

This is why I asked the question...

The current situation is not a planned Roll Back operation; it is simply data loss.

A few things I guess I could help clear up.

First, an operation doesn't need to be planned. It's not always an operation as in the sense that it is a planned course of action, but can be an operation in the sense of something is operating i.e. something is in effect. In the case of a rollback, the database is what's operating, and in a very specific manner - in a way that "rolls back" data in the database to what the data used to be in the past.

Second, despite how operations don't necessarily need to be planned, a rollback operation actually is planned. All rollback operations are planned. The function that is a rollback - that the data in a database will be set to what it used to be in the past through some specific method of achieving such - is planned in that it must have been programmed to function the way it does at some point. Dynamic rollbacks in the case of critical errors are still planned, because the rollbacks are setup to occur on the condition of the occurrence of a critical error. In other words, both the actual operation of a rollback itself and the condition in which a dynamic rollback will happen are determined at the time of development, thus meaning they are planned. What isn't planned is the literal time when a dynamic rollback will have to take place, since it's impossible to know when critical errors will arise and the conditions for starting the rollback will be met.

To clarify, a rollback is data loss, but it's a very specific type of data loss. The term rollback carries the implications that the data loss was intentional due to circumstances, controlled in how data was lost, and controlled in the scope of data that was lost. Just saying "data loss" doesn't give enough detail as to what actually happened because it lacks these implications. So, the term rollback is used instead of data loss because it better explains exactly what happened.

Also, rollbacks are used for a heck of a lot more than failed updates. It's most commonly used for data corruption, of which failed updates is only one of many causes.

The root cause of the problem here is the disconnects.

It may be that the last valid save point is the actual time of the disconnect from the server; and the client software continues to function. I don't know enough about that.

I'm just guessing, since it could be designed any number of ways, but... The database likely makes "save points" every set span of time (every X minutes, for example), and the player will d/c when data becomes corrupted for whatever reason. The last save point is what it will try to restore to, and (again, depending on their save frequency) may be many minutes ago.

It's worth noting that a d/c itself will not cause the data corruption, and thus will not cause the rollback. When you're d/ced, the server often doesn't even know that right away, so your character just stands there as though you were AFK until the server realizes the connection has been cut and logs you out server-side. It's more likely that the d/c is a symptom of the data corruption caused elsewhere. If you're still online when there's data corruption and the system needs to rollback to a save point, it would make sense that the server would be tasked with first disconnecting the player to ensure no new data is created until the rollback is complete.

Ildun · May 2019

Are we still playing Elders Roll Online?

Aarfie · May 2019

A database write can be within a transaction that if fails can be auto rolled back. Nobody here really knows exactly what is happening since you are just guessing the design. I don't see the point of this thread other than that ZOS needs to be made aware of it.

Donny_Vito · May 2019

A database write can be within a transaction that if fails can be auto rolled back

While this is true, I don't believe this is the case here. Potentially leveling up might be wrapped in a transaction, but even then I wouldn't think so. Transactions are for when you need to keep the data consistent (i.e. you use your debit/credit card and if the receiving company fails to get your payment then the transaction is rolled back and your debit/credit card is returned to it's previous point). It seems that the Save() function that is happening periodically is failing and not getting committed to the database for whatever reason. So if you want to call it a Rollback or Data Lost, the verbiage is really pointless. People are losing the time they put into their character (especially hearing about someone doing skyshards in a zone and then having to do it again).

Merlight · May 2019

Androconium wrote: »

Merlight wrote: »

Androconium wrote: »

The current situation is not a planned Roll Back operation; it is simply data loss.

What's your point? Every rollback is data lost.

My point is that what you are seeing is not a planned rollback of data. By definition, rollback is a planned process. A decision is actively made to restore a previous software image to mitigate some problem with the current image.

As the disconnection results in data loss, the cause of the problem here is completely different.

We don't know whether disconnection is the cause or result of data corruption, but either way, the rollback that follows is a planned countermeasure, an active decision to restore older consistent state.

Androconium · May 2019

Merlight wrote: »

Androconium wrote: »

Merlight wrote: »

Androconium wrote: »

The current situation is not a planned Roll Back operation; it is simply data loss.

What's your point? Every rollback is data lost.

My point is that what you are seeing is not a planned rollback of data. By definition, rollback is a planned process. A decision is actively made to restore a previous software image to mitigate some problem with the current image.

As the disconnection results in data loss, the cause of the problem here is completely different.

We don't know whether disconnection is the cause or result of data corruption, but either way, the rollback that follows is a planned countermeasure, an active decision to restore older consistent state.

The disconnections are happening because the server is overloaded (still); and we all complained about login queues, so they turned them off.
Your rollback 'feature' is NOT an active decision.

Your connection fails at some point.
Your client continues to function.
The game stopped processing your activity from the time of the connection failure.
Your client software finally times out and the game dies.
When you restart the game; and login; and select ANY character: the game picks up from the last transactions that the server logged.

It is not a planned countermeasure; it is a scripted process that runs as part of the character load process.

The problem is that the connection between your desktop client and the server database is cut, for whatever reason.
The data generated by your client software, after the disconnection, but before the client software fails, is LOST.

When you login again, you pick up where there server was at the time of the disconnection.

There is NO technical rollback of any software. For that to occur, as I said earlier, your currently loaded client software image would be overwritten with a previous version, that does not happen here.

Otherwise everyone would downloading new client images; or the server would be offline while the sysadmin were restoring the server image.

This issue is data loss caused by disconnection; it has nothing whatsoever to do with software rollback, active or passive.
For reference, go look up Norton Ghost and see the concepts of software imaging, as every operating system has some facility to enable this concept

idk · May 2019

Androconium wrote: »

Merlight wrote: »

https://en.wikipedia.org/wiki/Rollback_(data_management)

In database technologies, a rollback is an operation which returns the database to some previous state.

Yes. I've actually done it.
It's used to remove an upgrade that has failed.

An operation is planned. What is happening here is unplanned.
This symptoms so far suggest that nothing is being "rolled back", simply because it hasn't been captured in the first place.

This is why I asked the question...

The current situation is not a planned Roll Back operation; it is simply data loss.

I think this thread is splitting hairs unnecessarily and in manner that is not productive as this thread will do nothing to resolve the issue.

In the end it is irrelevant if it is an official rollback by Zos or not. Their characters are very literally being rolled back to a pervious point and it is very descriptive for these players to describe it that way to Zos. Much more descriptive and easier to understand that calling it data loss. Telling Zos I experienced a data loss does not tell them jack as it could mean many things. Saying I was playing in X area at Y time and I was rolled back tells Zos quite a bit.

So in the end, it does not mater what you want to call it. These players are best served with being descriptive as they have been.

Vandril · May 2019

Androconium wrote: »

Merlight wrote: »

Androconium wrote: »

Merlight wrote: »

Androconium wrote: »

The current situation is not a planned Roll Back operation; it is simply data loss.

What's your point? Every rollback is data lost.

My point is that what you are seeing is not a planned rollback of data. By definition, rollback is a planned process. A decision is actively made to restore a previous software image to mitigate some problem with the current image.

As the disconnection results in data loss, the cause of the problem here is completely different.

We don't know whether disconnection is the cause or result of data corruption, but either way, the rollback that follows is a planned countermeasure, an active decision to restore older consistent state.

The disconnections are happening because the server is overloaded (still); and we all complained about login queues, so they turned them off.

Your rollback 'feature' is NOT an active decision.

Your connection fails at some point.

Your client continues to function.

The game stopped processing your activity from the time of the connection failure.

Your client software finally times out and the game dies.

When you restart the game; and login; and select ANY character: the game picks up from the last transactions that the server logged.

It is not a planned countermeasure; it is a scripted process that runs as part of the character load process.

The problem is that the connection between your desktop client and the server database is cut, for whatever reason.
The data generated by your client software, after the disconnection, but before the client software fails, is LOST.

When you login again, you pick up where there server was at the time of the disconnection.

There is NO technical rollback of any software. For that to occur, as I said earlier, your currently loaded client software image would be overwritten with a previous version, that does not happen here.

Otherwise everyone would downloading new client images; or the server would be offline while the sysadmin were restoring the server image.

This issue is data loss caused by disconnection; it has nothing whatsoever to do with software rollback, active or passive.
For reference, go look up Norton Ghost and see the concepts of software imaging, as every operating system has some facility to enable this concept

That makes sense to me in most cases where the data lost is only of a minute or maybe two minutes of playtime, but what about those who have had "rollbacks" with over 15 minutes of lost playtime? That would seem to imply that the client continued to function despite being disconnected from the server for over 15 minutes, and that seems really far fetched.

Seri · May 2019

Vandril wrote: »

That would seem to imply that the client continued to function despite being disconnected from the server for over 15 minutes, and that seems really far fetched.

Especially when you factor in that other people in the zone all move, see you move, etc. And generally a bunch of people all in the same zone get disconnected at the same time. That _and_ the fact I got rolled back to a different zone (my house actually) means for that same logic means in my disconnected state I changed zone, and was talking to people in that zone.

Androconium wrote: »

The disconnections are happening because the server is overloaded (still); and we all complained about login queues, so they turned them off.

Your rollback 'feature' is NOT an active decision.

I'm not fully convinced server load has a huge amount to do with it. NA never had queues enabled and I was 'rolled back' last night on NA, at around 6am EST (so, dead of the night).

In reality it seems more like a protection mechanism, possibly within the megaserver architecture where changes from that "shard"/zone/instance don't get merged properly into the global state (I assume this happens periodically rather than continuously), thus that transaction is rolled back/discarded/whateveryouwanttocallit. This does make some assumptions on their server architecture, but from my general observations, the issues tend to be zone specific, and when the disconnections/rollbacks/dataloss happens, it's usually a whole bunch of people from that zone at once.

Edit: Expanding on this

The problem is that the connection between your desktop client and the server database is cut, for whatever reason.
The data generated by your client software, after the disconnection, but before the client software fails, is LOST.

A lot of what your client does requires server input. This includes all guild events, chat, inventory, most skills, ultimate, etc. If your server connection is cut, you will not be able to most or all of that stuff. Hence my feeling it's more a consistency issue between your specific server instance and it's database (or when replicating it's local database).

idk · May 2019

Vandril wrote: »

Androconium wrote: »

Merlight wrote: »

Androconium wrote: »

Merlight wrote: »

Androconium wrote: »

The current situation is not a planned Roll Back operation; it is simply data loss.

What's your point? Every rollback is data lost.

My point is that what you are seeing is not a planned rollback of data. By definition, rollback is a planned process. A decision is actively made to restore a previous software image to mitigate some problem with the current image.

As the disconnection results in data loss, the cause of the problem here is completely different.

We don't know whether disconnection is the cause or result of data corruption, but either way, the rollback that follows is a planned countermeasure, an active decision to restore older consistent state.

The disconnections are happening because the server is overloaded (still); and we all complained about login queues, so they turned them off.

Your rollback 'feature' is NOT an active decision.

Your connection fails at some point.

Your client continues to function.

The game stopped processing your activity from the time of the connection failure.

Your client software finally times out and the game dies.

When you restart the game; and login; and select ANY character: the game picks up from the last transactions that the server logged.

It is not a planned countermeasure; it is a scripted process that runs as part of the character load process.

The problem is that the connection between your desktop client and the server database is cut, for whatever reason.
The data generated by your client software, after the disconnection, but before the client software fails, is LOST.

When you login again, you pick up where there server was at the time of the disconnection.

There is NO technical rollback of any software. For that to occur, as I said earlier, your currently loaded client software image would be overwritten with a previous version, that does not happen here.

Otherwise everyone would downloading new client images; or the server would be offline while the sysadmin were restoring the server image.

This issue is data loss caused by disconnection; it has nothing whatsoever to do with software rollback, active or passive.
For reference, go look up Norton Ghost and see the concepts of software imaging, as every operating system has some facility to enable this concept

That makes sense to me in most cases where the data lost is only of a minute or maybe two minutes of playtime, but what about those who have had "rollbacks" with over 15 minutes of lost playtime? That would seem to imply that the client continued to function despite being disconnected from the server for over 15 minutes, and that seems really far fetched.

You are correct that it is more descriptive, and still correct, to call it a rollback. Calling it such does not mean Zos did an official rollback.

Zos is able to easily understand what they player is conveying, much more so than if the player said they experienced data loss since that could mean much more than just the servers did not save my data.

I speak from experience and I am not talking about a couple decades working with networks and servers and such, but I experienced this very same issue 5 years ago and Zos had no problems with me explaining I experienced a rollback.

Edit: and as Seri described it above, that is a classic case that there was a rollback caused by something. Calling it merely a data loss does not even come close to providing a worthy description of the experience.

Androconium · May 2019

Seri wrote: »

Vandril wrote: »

That would seem to imply that the client continued to function despite being disconnected from the server for over 15 minutes, and that seems really far fetched.

Especially when you factor in that other people in the zone all move, see you move, etc. And generally a bunch of people all in the same zone get disconnected at the same time. That _and_ the fact I got rolled back to a different zone (my house actually) means for that same logic means in my disconnected state I changed zone, and was talking to people in that zone.

Androconium wrote: »

The disconnections are happening because the server is overloaded (still); and we all complained about login queues, so they turned them off.

Your rollback 'feature' is NOT an active decision.

I'm not fully convinced server load has a huge amount to do with it. NA never had queues enabled and I was 'rolled back' last night on NA, at around 6am EST (so, dead of the night).

In reality it seems more like a protection mechanism, possibly within the megaserver architecture where changes from that "shard"/zone/instance don't get merged properly into the global state (I assume this happens periodically rather than continuously), thus that transaction is rolled back/discarded/whateveryouwanttocallit. This does make some assumptions on their server architecture, but from my general observations, the issues tend to be zone specific, and when the disconnections/rollbacks/dataloss happens, it's usually a whole bunch of people from that zone at once.

Edit: Expanding on this

The problem is that the connection between your desktop client and the server database is cut, for whatever reason.
The data generated by your client software, after the disconnection, but before the client software fails, is LOST.

A lot of what your client does requires server input. This includes all guild events, chat, inventory, most skills, ultimate, etc. If your server connection is cut, you will not be able to most or all of that stuff. Hence my feeling it's more a consistency issue between your specific server instance and it's database (or when replicating it's local database).

I'll happily accept all the arguments raised here. As I said earlier, I don't have intimate experience with client/server operation.
I do however, have experience in software rollback functions on mainframes, minicomputers (when they existed) and PCs. So I have a specific view on what a rollback is; along with roll-forward of transactions. This is why I am insisting that the fundamental problem here is the disconnections; with data loss being the obvious symptom.

My original intent with this post was to highlight the fact that this behaviour is not only abnormal, but indicative of a more serious problem. Comments suggesting that 'rollback' is both routine and and minor are disingenuous.

Merlight · May 2019

Androconium wrote: »

Your connection fails at some point.

Your client continues to function.

The game stopped processing your activity from the time of the connection failure.

Your client software finally times out and the game dies.

When you restart the game; and login; and select ANY character: the game picks up from the last transactions that the server logged.

It is not a planned countermeasure; it is a scripted process that runs as part of the character load process.

The problem is that the connection between your desktop client and the server database is cut, for whatever reason.
The data generated by your client software, after the disconnection, but before the client software fails, is LOST.

When you login again, you pick up where there server was at the time of the disconnection.

There is no client-generated data. You cannot make any progress on your character without connection to server. Character movement is kinda client-side, in that the client allows you to walk around freely, sending that information to the server, but not waiting for acknowledgement. The moment you try to use an ability, harvest a resource node or speak with NPC, the client requires response from the server. How do I know? A few months back I was on a really really bad Wi-Fi, and I could run around just fine, but whenever I actually wanted to loot something I had to wait several seconds, sometimes tens of seconds.

The data loss you're observing, is data generated on the server, at some point floating somewhere in the server's memory, but either not making it into the database, or being rolled back for who knows why.

Androconium wrote: »

There is NO technical rollback of any software. For that to occur, as I said earlier, your currently loaded client software image would be overwritten with a previous version, that does not happen here.

Otherwise everyone would downloading new client images; or the server would be offline while the sysadmin were restoring the server image.

Client image is just artwork and UI. There's no character data, inventories and such stored client-side. Only UI/add-on saved variables, and those you can delete any time without losing anything related to your characters' state in game world; you only lose some local configuration settings.

As for sysadmin restoring server image (I assume you mean database), that's probably your biggest confusion about what a rollback means. Rollback in databases is a very common operation happening on transaction level. There's no need for admin intervention, they're coded in the software to handle error conditions. They can rollback individual transactions that went wrong for whatever reason, while the rest of the system continues its function, properly committing transactions pertaining to other clients.

Seri wrote: »

Especially when you factor in that other people in the zone all move, see you move, etc. And generally a bunch of people all in the same zone get disconnected at the same time. That _and_ the fact I got rolled back to a different zone (my house actually) means for that same logic means in my disconnected state I changed zone, and was talking to people in that zone.

There's no way you would see other people move around, and them see you move around, after you lost connection to the server. How could it happen? Game client guessing where they'd move were you still connected?

As for talking to people in zone after disconnection... has ESO client just passed the Turing test?

If you changed zones, looted some stuff and disconnected, and later found yourself in another zone without the loot, it's probably a problem in inter-server communication, where the old zone's server didn't sign you out properly, so from the megaserver's point of view, you shouldn't have been looting stuff in the new zone, and it rolls that back you "cheater"!