Ce modèle est connu sous quelques noms (Ex. Backing Store, Write-Behind, etc ...). Cela est souvent observé dans les technologies Data Grid/Cache ainsi que dans d'autres. Généralement, les objets de domaine sont stockés dans une sorte de FIFO ou une file d'attente prioritaire, puis un répartiteur les déquiert sur un thread ou un processus alternatif et les transmet à votre DAL réelle. Les files d'attente peuvent être en mémoire ou être réellement placées sur une file d'attente réseau telle qu'ActiveMQ ou MSMQ. En outre, j'ai vu des scénarios où il y a des files d'attente séparées pour chaque type d'opération DB.
Dans de nombreux cas, ceci est implémenté comme une façade devant votre DAL représentant la même interface. De cette manière, d'autres applications pensent qu'elles communiquent avec la «vraie» LDA et sont extraites d'autres préoccupations connexes. Ce découplage vous permet de le changer si vous le souhaitez. Lorsque les données d'objet sont soumises à la façade, les données sont mises en file d'attente et le contrôle est renvoyé à l'application appelante. Une fois mis en file d'attente, vous pouvez simplement effectuer des mises à jour/insertions par lots ou continuer à traiter les éléments un par un. Gardez à l'esprit que la notion de transaction prend une signification très différente, donc vous devrez y réfléchir.
Bien qu'il existe des technologies qui font cela ... Il s'agit plus d'un modèle que d'une technologie unique. Je n'ai pas d'exemple à portée de main, mais vous pouvez consulter la documentation de la grille de données à partir de produits comme Oracle Coherence. Recherchez les magasins de soutien.
Et celui-ci: http://stackoverflow.com/questions/2811980/buffering-db-inserts-in-multithreaded-program/2812289 – Justin