Zverek, очень хорошие вопросы. Приятно общаться с человеком, которому голова дана не только для того чтоб шапку на ней носить  То, что опыта программного дизайна на Java маловато - это ничего, со временем пройдет.
Теперь про твою задачу. То, что ты рассказываешь, делает ситуацию еще хуже! Я-то было подумал, что ты пытаешься сваять толстого удаленного универсального датабазного клиента (типа выполнять команды SQL), а оказывается вон оно что. Ну что ж, давай по порядку. Если точнее, в том порядке, в котором мне это видится.
Сразу сообщу хорошую новость: все твои вопросы имеют решения. Просто будь готов к тому, что твои изначальные посылки могут быть не совсем верны. Прежде всего - идея о том, что юзеры должны ходить в базу под своим именем.
Чем плохи датабазные средства разграничения прав доступа
На самом деле ничем они, конечно, не плохи, но вот использовать и полагаться на них - в данном случае не стОит. Раздельные датабазные логины полностью оправдывали себя в эпоху двухзвенных приложений баз данных - когда гуевый клиент напрямую издавал команды к SQL серверу. В этих условиях другого способа управлять доступом, кроме как устанавливать разным юзерам разные права на уровне объектов СУБД, просто не было в природе.
Но вот на авансцену вышли системы массового обслуживания - в первую очередь веб приложения (но и не только!), и ситуация коренным образом изменилась. Теперь о том, чтобы раздавать каждому юзеру по отдельному датабазному логину, не могло быть и речи. Но дело даже не только в этом. Самое главное, возникла необходимость каким-то образом централизовать датабазную логику. Как ответ на это требование, родилась концепция приложения трехзвенной архитектуры: гуевый клиент - сервер приложения - сервер СУБД.
Это был исключительно важный момент в истории развития компьютерной мысли. Возможность сосредоточить всю логику по обработке данных в одном месте позволила (теретически) создавать приложения намного более пуленепробиваемые, более надежные, более масштабируемые, более удобные в плане управления и развития.
Одним из важнейших следствий такого разделения обязанностей стало то, что теперь клиенту совершенно не нужно было знать о том, где и в каком виде хранятся данные. Это избавило прикладных разработчиков от необходимости кодировать низкоуровневую датабазную логику и позволило им плотнее заняться вопросами собственно пользовательского интерфейса. Так вот, применительно к теме нашего обсуждения, это также означало то, что вся возня с различными датабазными логинами теряла всякий смысл: ведь юзеры теперь ходили в базу не напрямую, а через посредство сервера приложений!
Теоретически можно было бы, конечно, предусмотреть несколько разных датабазных ролей по уровню доступа: админы, зарегистрированные юзеры, анонимоусы и пр., и выполнять операции от имени клиента, используя тот или иной предопределенный логин, в зависимости от типа клиента. Но на практике оказалось, что все это не имеет большого смысла, и вот почему.
Это только кажется, что встроенная в СУБД система разграничения прав доступа - очень мощная и гибкая. В действительности, и особенно в условиях использования СУБД в рамках трехзвенной архитектуры, при организации контроля доступа возникает масса проблем, для которых датабазная секьюрити не может предложить решения. Например:
- как ограничить доступ к части таблицы на основе некоего условия?
- как контролировать, что можно и что нельзя модифицировать, если это зависит от значений данных?
- как контролировать выполнение операций, которые вообще не имеют отношения с СУБД (например, рассылка готовых отчетов)?
Если говоритиь строго, многие из этих вещей таки можно реализовать средствами датабазной секьюрити, но - ценой усложнения структуры самой базы. То есть: база данных и без того вещь непростая - там нужно думать и о производительности, и о конкурентом доступе, и о физическом размещении с учетом требований к масштабированию, копированию/восстановлянию и пр., и об удобстве программного представления, и еще о куче разных вещей. Если мы в эту картину еще введем всякие извороты, которые диктуются логикой управления доступом, то можем запросто вообще за деревьями потерять из виду сам лес.
Как ответ на перечисленные сложности и ограничения, передовая энетрпрайзная мысль выработала следующий практический подход: коль скоро нам все равно нужна какая-то система аутентификации (грубо говоря, логин/пароль), и привязанная к ней система авторизации (например, доступ к веб страницам) помимо дотабазной, то не проще ли весь контроль над пользовательскими полномочиями вынести вообще за датабазные скобки?
Поэтому в большинстве современных приложений аппсервер ходит в базу под одним и тем же аккаунтом, а для контроля доступа к различным функциональным аспектам приложения использует свою, доморощенную систему разграничения прав. Помимо преимуществ, о которых уже говорилось, это позволяет также без каких-либо проблем использовать единый пул датабазных соединений. Так что будем считать, на вопрос 2) мы ответили. А теперь о главном вопросе:
Цитата(Zverek @ 16.11.2006, 04:39  ) | | 1) Мое приложение работает следующим образом: в начале работы клиент коннектится к БД (через Веб-сервис), выбирает данные, на их основе создаёт объекты. В процессе дальнейшей работы, при изменении, созданнии или удалении объектов, анналогичные действия выполняются и с записями в БД (т.е. выполняются UPDATE, INSERT, DELETE). НО данные сразу не коммититятся, коммит происходит в тот момент, когда пользователь нажимает кнопку "Сохранить". Если бы у меня коммитилась каждая операция, то действительно для каждой DML операции, можно было бы открывать соединение, и по её выполнении соединение закрывать. |
Ты понимаешь, что ты сделал? Ты сделал классическое двухзвенное приложение, со всеми присущими ему недостатсками, и облачил его в подобие трехзвенного. Но суть-то осталась та же!
Чем плоха двухзвенка
Самый главный недостаток двухзвенной архитектуры - это то, что операции по доступу к данным со стороны разных клиентов взаимно никак не синхронизированы, и полагаться на помощь в разрешении конфликтов мы можем только на сам сервер СУБД. Что отнюдь не всегда гарантирует нас от ошибок конкурентного доступа. При этом самый худший вид сценария такого рода - это когда пользователю позволяют удерживать открытую транзакцию. Тут у нас открывается самый широкий простор для множественных нежелательных проявлений http://forum.vingrad.ru/topic-105840/0.html#entry805943 (с) мой. Вот навскидку самый простой и совершенно реальный сценарий:
- Юзер А открыл список кастомеров.
- Юзер А открыл форму данных кастомера 12345.
- Юзер А изменил поле PHONE_NUMBER кастомера 12345.
- Юзера А отвлекли вопросом о стоимости путевок в Анталию, потом позвали на перекур, который плавно перетек в обеденный перерыв.
- Юзер Б захотел открыть список кастомеров.
Так вот, юзер Б будет очень долго пялиться в курсор "песочные часы", не имея ни малейшего понятия, что происходит и когда это кончится.
Что делать
А делать надо очень просто: вот скажи, почему бы тебе не делать коммит после каждой вставки/обновления/удаления? Может, ты хочешь предотвратить возможность просмотра сырых, недоделанных объектов? Типа, сначала сформировать всю накладную, строка за строкой, а потом ее всю целиком сделать доступной? Ну так для этого есть другие решения.
Вообще, то, что ты таскаешь по сети эквиваленты ResultSet, говорит для меня о том, что тебе было бы неплохо ознакомиться с энтерпрайзным паттерном http://en.wikipedia.org/wiki/Data_Transfer_Object (он же Value Object).
И в заключение главное: чем меньше клиент в распределенной системе знает о каких-то там базах данных, тем лучше и надежнее будет работать вся система в целом, и тем крепче и спокойнее будет сон у ее разработчиков
|