|
ru.website
- RU.WEBSITE -------------------------------------------------------------------
From : Serge Shikov 2:5020/400 01 Jul 2001 12:20:07
To : All
Subject : Re: Литература по PHP
--------------------------------------------------------------------------------
pavel kurnosoff wrote:
>
> >> плюс его установка, плюс его настройка, плюс смена железа.
> SS> What for?
> а затем. сейчас у нас на двух серверахз крутится порядка 30 сайтов в боевом
> режиме. плюс еще несколько в процессе разработки. если их всех враз заменить
> на яву, да добавить всё то тряхомудие, которое требует j2ee - всё умрёт.
И при чем тут ява? Если вы захотите на имеющуюся машину добавить еще
задачи - железо все равно придется расширять и добавлять, независимо от
технологий. А может и не потребуется.
> >> а, дык всё-таки всё на так легко и непринуждённо? значит чудес не
> >> бывает?
> SS> А чудес никто и не обещал. Я просто намекаю, что некоторые "гуры"
> SS> вполне могли и не попробовать ;-)
> а не хочу. заплатить мне за это не заплатят, а занятие в свободное время я
> могу найти и получше.
Hу и не хоти. Кто заставлял-то?
> >> ну уж напрягись давай и объясни, зачем мне нужны еще какие-то
> >> транзакции в однопоточном приложении, где persistency обеспечивает
> >> rdbms со своими транзакциями.
> SS> rdbms допустим может что-то обеспечить только внутри себя.
> да пусть хоть на луне обеспечивает. главное, что единственное место, где
> возможны коллизии защищено транзакцями.
Кто сказал, что единственное? Hу представь для простоты хотя бы _две_
СУБД.
> >> так что пока всё еще 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.
Т.е. ты с _бизнес-объектами_ намертво привязан к mod_fastcgi и Апачу?
Hашел чем хвастать...
> SS> Я не говорю, что они уже пошли лесом, но об этом
> SS> надо думать, и думать серьезно.
> куда пошли?!
В пешее эротическое путешествие они пошли.
> SS> Точно такие же проблемы возникают,
> SS> если имеет место кластер - HTTP обрабатывается несколькими серверами,
> SS> а бизнес-объект должен жить где-то в одном месте (или
> SS> свободно перемещаться). Ты гарантируешь, что твой perlmod сам по себе
> SS> это обеспечит?
> см. выше постановку задачи. ты уже пошёл в степь, про которую я ничего не
> утверждал.
Постановка таже самая. Я утверждаю простую вещь - бизнес-объекты не
должны жить внутри httpd, нечего им там делать. И они не должны быть
привязаны к какой-то там обработке http-запросов - не их это дело. У них
свое время жизни, свои транзакции, более того - с ними могут работать
вовсе не через WEB, а скажем локально через интранет, из программы на
Дельфи. Вот вообрази такое, и расскажи, накойхер программа на Дельфи, у
которое свое отображение данных, будет ходить к тебе на апач, чтобы
взять оттуда что? И транзакции будет обеспечивать через него же...
> SS> на IIS вдруг? Мне вот приходится иногда про это задумываться. И чем
> SS> дальше думаю - тем больше убеждаюсь, что надо отдельный сервер. Как
> SS> его будут звать, EJB или нет - не так важно. Очень может быть, что
> SS> звать его будут COM+ ;-), а объекты будут например лазать в Excel за
> SS> данными - почему нет? Почему бизнес-объект обязательно должен жить в
> SS> Апаче, если данные его живут под виндой? Мне это пока не надо, но
> SS> приятно, знаешь ли, ощущать, что я и это могу, если приспичит.
> да? можешь?
Угу. Уж всяко на какой-то апач я тут никак не завязан.
> уже есть рабочие гейты ejb-com?
Есть. Уже давно над этим подумали, чай не первый год то и другое
существует.
--- ifmail v.2.15dev5
* Origin: home (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
