Refactoring Database Access in Marauroa: Difference between revisions

Content deleted Content added
imported>Hendrik Brummermann
imported>Kymara
grammar and spelling and readability
Line 1:
At the moment database access in marauroa is designed for a single thread application. While this does workworks most of the time in turn based games (yes, Stendhal is turnedturn based internally), it prevents doing non time critical stuff in another thread. In Stendhal we have the problem that any update or delete operation to the gameEvents table that takes more than a couple of seconds, kills the server.
 
== Requirements ==
Line 23:
=== Where did IDatabase / JDBCDatabase go? ===
 
It was replaced by smaller classes specializedspecializing onin one task each. They can be found in the package <code>marauroa.server.game.db</code> endingand they end with "DAO".
 
=== What are those new ...DAO classes? How do they work? ===
 
TheyDAO arestands for "data access object". The basic idea is, and has been from the start, that the database related code is not in the original classes but at some central point outside the game logic. This used to be JDBCDatabase, but one single class for all database operations is very unhandy. So JDBCDatabase has been splittedsplit into a number of small classes focused on one area each: AccountDAO, CharacterDAO, GameEventDAO...
 
These classes replace the old IDatabase / JDBCDatabase and do the database stuff. All of their methods have two signatures: One with gets ana DBTransaction object as first parameter and one without. This is for your convenience: In most cases it those functions are not part of a larger context so you do not have to care about transactions at all because: the DAO-classes do the transaction handling on their own. There are, however, a small number of cases in which you want to do multiple calls to DAOs in one single transactionstransaction. In this case you get a DBTransaction from the TransactionPool and provide it as first parameter to DAO-methods. After you are done you must either commit or rollback your changes with the appropriate methods in the class TransactionPool.
 
=== I have extended the JDBCDatabase class. How does this work with DAOs? ===
Line 35:
DAO classes should never be instantiated directly. Instead you should (and marauroa does) use the DAORegistry. This allows you to write a subclass of a DAO provided by marauroa and register it instead. If you are familiar with Spring, this is a similar concept. But without all the bulk of xml configuration files, parameter injection and interfaces with only one single implementation.
 
Imagine you want to subclass the CharacterDAO with your class SomeGameCharaterDAOSomeGameCharacterDAO:
public class SomeGameCharacterDAO extends CharacterDAO {
...
 
You simply register it as
DAORegistry.get().register(CharacterDAO.class, new SomeGameCharaterDAOSomeGameCharacterDAO());
Note: In the register call the first parameter is the parent claseclass you want to replace.
 
 
=== What are those database adapters for? ===
 
TheThey are a thin layer of database abstraction. This allows us to not only support MySQL but also database systems with don't require an external server.
 
 
Line 66:
=== What happened to Transaction, JDBCTransaction, Accessor, JDBCAccess? ===
 
They wherewere replaced with DBTransaction. You can get a DBTransaction from the TransactionPool. Make sure that you commit or rollback it after use.
 
=== What happendhappened to JDBCSQLHelper and StringChecker? ===
 
They have been moved to marauroa.server.db