Asynchronous Database Access: Difference between revisions

Content deleted Content added
imported>Hendrik Brummermann
from bug tracker
imported>Hendrik Brummermann
No edit summary
 
(43 intermediate revisions by 2 users not shown)
Line 1:
{{Navigation for Marauroa Top|Internals}}
{{Navigation for Marauroa Developers}}
 
 
{{Future Concept}}
 
 
Line 15 ⟶ 12:
== Kinds of database operations ==
 
Most of the database operations in marauroa are write only, making it easy to put them into a queue for asynchronous processing. Read operations are more difficult to handle because the data returned by them is needed. That is obviousobviously the reason why it is read in the first place.
 
There are three kinds of read operations:
Line 44 ⟶ 41:
 
 
== Implementation ==
== Some quick ideas on how to ==
 
 
Note: This sections needs more thinking.
 
ThereMarauroa should behas a DatabaseOperationQueueDBCommandQueue, which is singleton and has a background thread to execute enqueued DatabaseOperationsDBCommands. DatabaseOperationDBCommand is an interface that specifies an execute()-method, that handlesprocessed the database operationrequest by invoking the DAO-classes. It is called from the background thread of DatabaseOperationQueueDBCommandQueue.
 
The following example for a simple write operation assumes that GameEvent implements/extends DatabaseOperationDBCommand:
 
DatabaseOperationQueueDBCommandQueue.get().enqueue(
new GameEvent(attacker.getName(),
"attack", target.getName());
Line 61 ⟶ 55:
Since we ignore 1) for now, this leaves us with 2): We need a way to receive the data produced by an read operation:
 
UUID uuid = DatabaseOperationQueueDBCommandQueue.get().enqueueAndNotifyenqueueAndAwaitResult(
this, new GetCharacterList(username));
 
The DatabaseOperationQueueDBCommandQueue will process the GetCharacterList at some future time in the background thread. It will then put the GetCharacterList which now contains the results from the database in a second queue ("waiting to be fetched by program"). Here comes the tricky part: We need a way to notify the program in the thread that requested the operation about the results. The easiest way is to remember the requesting thread by Thread.getCurrentThread() and provide a List<DatabaseOperationDBCommand>
getResults() method, which fetches all results of OperationsCommands enqueueenqueued by the current thread.
 
We havehad to decide here whether we wantwanted an ''interrupt'' or ''polling'' based approach: An interrupt based approach would then distribute the results to various program parts of the current thread using an interface DatabaseOperationResultReceiverDBCommandResultReceiver<T extends DatabaseOperationDBCommand>, which is implemented by those classes who requested the data. AWe chose a a polling based
approach. would result inHere, the program parts to look for specific results. So theThe program part that sends the character list back to the client would callcalls:
List<GetCharacterList> DatabaseOperationQueueDBCommandQueue.get().getResults(this).
 
 
[[Category:Marauroa]]
{{#breadcrumbs: [[Marauroa]] | [[Navigation for Marauroa Developers|Internals]] | [[Marauroa Roadmap|Roadmap]] | [[Asynchronous Database Access]] }}