|
ru.website
- RU.WEBSITE -------------------------------------------------------------------
From : pavel kurnosoff 2:5030/661.25 30 Jun 2001 15:38:42
To : Serge Shikov
Subject : Литература по PHP
--------------------------------------------------------------------------------
28 Jun 01 11:58, you wrote to all:
>> плюс его установка, плюс его настройка, плюс смена железа.
SS> What for?
а затем. сейчас у нас на двух серверахз крутится порядка 30 сайтов в боевом
режиме. плюс еще несколько в процессе разработки. если их всех враз заменить на
яву, да добавить всё то тряхомудие, которое требует j2ee - всё умрёт.
>> а, дык всё-таки всё на так легко и непринуждённо? значит чудес не
>> бывает?
SS> А чудес никто и не обещал. Я просто намекаю, что некоторые "гуры"
SS> вполне могли и не попробовать ;-)
а не хочу. заплатить мне за это не заплатят, а занятие в свободное время я могу
найти и получше.
>> ну уж напрягись давай и объясни, зачем мне нужны еще какие-то
>> транзакции в однопоточном приложении, где persistency обеспечивает
>> rdbms со своими транзакциями.
SS> rdbms допустим может что-то обеспечить только внутри себя.
да пусть хоть на луне обеспечивает. главное, что единственное место, где
возможны коллизии защищено транзакцями.
>> так что пока всё еще perldoc perlmod.
SS> Кроме того, persistency тебе допустим обеспечивает mod_perl, сохраняя
SS> где-то у себя (Apache::DBI например) открытые соединения с базой. А
SS> иначе какие транзакции? Hо при этом возникают резонные вопросы -
SS> первый HTTP-запрос обработан одной дочкой апача, второй - уже другой.
SS> У каждой по своей копии mod_perl, по своей копии $dbh, и т.п. И где у
SS> нас опять транзакции?
честно? понятия не имею. я не пользуюсь mod_perl. а mod_fastcgi с session
affinity мне обеспечивает попадание в ту же копию. куками, конечно. хотя может и
по ip.
SS> Я не говорю, что они уже пошли лесом, но об этом
SS> надо думать, и думать серьезно.
куда пошли?!
SS> Точно такие же проблемы возникают,
SS> если имеет место кластер - HTTP обрабатывается несколькими серверами,
SS> а бизнес-объект должен жить где-то в одном месте (или
SS> свободно перемещаться). Ты гарантируешь, что твой perlmod сам по себе
SS> это обеспечит?
см. выше постановку задачи. ты уже пошёл в степь, про которую я ничего не
утверждал.
SS> на IIS вдруг? Мне вот приходится иногда про это задумываться. И чем
SS> дальше думаю - тем больше убеждаюсь, что надо отдельный сервер. Как
SS> его будут звать, EJB или нет - не так важно. Очень может быть, что
SS> звать его будут COM+ ;-), а объекты будут например лазать в Excel за
SS> данными - почему нет? Почему бизнес-объект обязательно должен жить в
SS> Апаче, если
SS> данные его живут под виндой? Мне это пока не надо, но приятно, знаешь
SS> ли, ощущать, что я и это могу, если приспичит.
да? можешь? уже есть рабочие гейты ejb-com?
pavel
--- GoldED+/W32 1.1.4.7
* Origin: there's no tomorrow (2:5030/661.25)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
