Не думайте, что вы можете сохранить буфер без написания кода самостоятельно. Я бы предпочел посылать журналы как AdoNetAppender, так и RollingFileAppender. Первый обеспечит регулярное ведение журнала в базе данных, а второй обеспечит запись последних журналов на диск.
Обновление : в свете ваших последующих комментариев я вижу, как трудно объединить ведение журнала для двух разных источников (одной базы данных и одного локального хранилища, файла или локальной базы данных).
По моему мнению, вы должны обязательно использовать log4net для достижения наилучших результатов: проверенной и надежной основы для сбора данных журнала из приложения и маршрутизации этих данных в принимающие системы. Построение отказоустойчивой системы поверх log4net, хотя это не то, для чего она предназначена. Например, не существует модели процесса, которая могла бы собирать фрагменты после сбоя приложения.
Вместо этого обработайте аварийное переключение в принимающей системе. Аварийное переключение на уровне базы данных и на уровне сети проделывает долгий путь, тем не менее, вам не гарантируется 100% безотказная работа. Вход в локальное хранилище и последующий процесс сбора журналов и отправки их в базу данных сведет к минимуму риск потери данных журналов, и в то же время вам не придется объединять журналы из двух разных хранилищ. Более того, ведение журналов по-прежнему простое и быстрое и, таким образом, оказывает незначительное влияние на приложение.
Альтернативой может быть вход в локальную базу данных и выполнение задания базы данных для извлечения данных в основную базу данных. Вы также можете использовать очереди. Существует образец MsmqAppender , с которого можно начать. Если вы используете MS SQL Server, вы даже можете использовать Service Broker для его возможностей организации очередей.