[to devs] why can't the database be shared between Siel & Lumiel

I remember there was an experiment for a little while here at GamezAion, with two servers available at login but they shared characters. What was the problem with that setup, exactly?

IMO that was much better than the current setup -- both from the player satisfaction perspective and for server load alleviation, because my impression is that a lot of people here (me included, and all my friends) are not willing to start from scratch on the new server now -- or if they do, they might want to at least be able to transfer some goods from the old characters to the new ones -- which seems to be impossible in the current setup.

I am a software engineer (though I'm not familiar with the details of Aion Lightning's server architecture) and I have serious doubts that the move to the current setup was well thought out and that is helping much with preventing crashes due to overpopulation - and I think it's actually worse than the setup that would allow sharing the user characters between the servers, which would also be a much desirable setup for the community.

I am assuming that in both setups there are 2 main server processes, each keeping track of its separate connection pool (one for each server). Devs please correct me if that's not true. So in both setups the reduction in client handling per server would be the same -- but the load balancing would most likely be improved if the character data were shared (because if one server/channel was full, I and many others would have no problem logging in on the other server, but in the current server setup I have no interest in starting "fresh" on Lumiel).

I know that it was a little weird that the Trade Broker data was different on the two servers, but that's not a game-breaking feature, users should just be made aware of that -- but at least they can still work on their characters, no matter what "server" they connect.

So? Any real technical issues with sharing the database between the servers?

 

il ltell u wts the problem.
if u put 2 chennals on 1 host, u didnt achive anythin, u even lost some preformance on the maintance on the 2nd chennal.(that was the experiment with the shared DB)
BUT
if u put 2 chennals on different hosts and split the community, that will surely ease the lags/crash etc'
also it means u cant have shared DB. since its 2 different pcs, i mean u probably can do somethin, but that will open alot of exploit oppertunitys.

 

the emulator stores some of its data in memory rather than real time db transfers which increases performance so they will be problems like duping and certain things not saving in real time.

 

Thanks for the quick answer Carl.
I can see how that can be a problem.. but only if there is concurrency involved. I assume memory buffering happens anyway, for each server process, no matter the setup -- so the performance should be the same in both cases, correct? (as in both setups we'd have two server processes doing this kind of buffering for the same total number of players - theoretically). I could see some slight performance hit caused by table locking -- when flushing data into the database, but these should be minimal, because characters from a single account cannot be logged on both servers at the same time and players from different servers cannot directly interact with each other, I would think there should be no [major] concurrency issues for the shared resources.

I can only think of the legion warehouse right now as a shared resource that could be accessed simultaneously from both servers.. But those operations could be made atomic at database level -- as they are slow and low-frequency enough to not require memory buffering.. I am thinking of the way the Trader code works now, no multiple persons can buy the same item there, even if they press the "Buy" button at the same time. Well I agree that's happening within a single server process so they might have used memory semaphores to implement that. But I think that for slow operation like these low level database locking should work as well.

So were there concrete, confirmed cases of duping or other concurrency issues that surfaced in that experimental dual-server setup?