|
Распределенные транзакции / Совместное использование одной коннекции
|
|||
---|---|---|---|
#18+
Доброго времени суток ! Господа, подскажите как можно решить такую проблему: Имеется сложная система - интерфейс написан на mod_perl скриптах, а ядро системы на С++, причем интерфейсные скрипты часто вызывают функции ядра системы и в этих функциях ядра требуется работа в той же транзакции, что была начата в вызывающей программе. Собственно, для этого необходимо передать одним из параметров handler коннекции. Но достаточно ли этого? Совместимы ли возвращаемые значения функции perl[Pg.pm]::PQconnectdb и C[libpq]::PQsetdbLogin ? На бинарном уровне или нужно будет писать какую-то подпрограмму для преобразования полей этих объектов? А достаточно ли вообще говоря передать объект, описывающий коннекцию, чтобы в обычном режиме продолжить выполнять команды в рамках транзакции, которая начата в другом процессе/программе ? С уважением. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2004, 08:57 |
|
Распределенные транзакции / Совместное использование одной коннекции
|
|||
---|---|---|---|
#18+
Внутри c++ ядра или в perl-xs вы деалете fork? Если нет, то наверное проблем не должно быть, иначе не могу сказать, что вас может ожидать. Загляните в исходники DBD::Pg, в файле dbdimp.c подключение делается с помощью функции PQconnectdb(). ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2004, 10:39 |
|
Распределенные транзакции / Совместное использование одной коннекции
|
|||
---|---|---|---|
#18+
Ок. Хорошо, то есть получается что эти значения абсолютно совместимы, но не ожидал что проблема может возникнуть на более низком уровне - сокетов. А в чем здесь собственно грабли? Ведь одновременно запросы не будут идти от более чем одного процесса? fork() делается только в Си-ядре, но коннекция у меня вызывается в уже ответвленном дочернем процессе, не предполагается работа с ним в родительском процессе. Единственная задача одит. процесса - ответвлять потомков на каждый поступающий запрос. Спасибо за ссылку. Изучаю. Кстате, по моему разумению нужно передавать объект-хэдлер коннекции не только от интерфейсных программ, но и наоборот, возвращать от ядра вместе с результатами, так как в объекте должны меняться какие-то внутренние состояния? Правильно. Спасибо за ответ. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2004, 12:04 |
|
Распределенные транзакции / Совместное использование одной коннекции
|
|||
---|---|---|---|
#18+
не ожидал что проблема может возникнуть на более низком уровне - сокетов. А в чем здесь собственно грабли? Я не знаю, есть ли здесь проблема, но судя по обсуждениям на сайте постгреса, может оказаться. в этих функциях ядра требуется работа в той же транзакции, что была начата в вызывающей программе коннекция у меня вызывается в уже ответвленном дочернем процессе, не предполагается работа с ним в родительском процессе Или это противоречащие утверждения, или я чего-то недопонимаю. Если в вызывающем процессе (ребенок апача с мод-перлом) был сделан коннект и начата транзакция (первая цитата), то как же "коннекция вызывается в уже ответвленном дочернем процессе"? Вы ведь не думаете, что можно сделать "connect, begin, update, disconnect", затем "connect, update, commit, disconnect" - и это будет одна транзакция? Или вы описали две схемы - существующую и предполагаемую? Разъясните пожалуйста. нужно передавать объект-хэдлер коннекции не только от интерфейсных программ, но и наоборот, возвращать от ядра вместе с результатами, так как в объекте должны меняться какие-то внутренние состояния? Правильно. Возможно. Но реально ли это? В общем, мне кажется, что "connect, fork" - неправильный путь. Но может быть я ошибаюсь. P.S.: Когда-то натолкнулись на грабли. В одном из перловых модулей, загружаемых апачем-отцом при стартапе посредством PerlScript, создавался коннект к базе и загружались данные из базы в память. Затем каждый из форкнутых детей считал, что к базе он подключен (глобальная переменная $dbh в том модуле была определена, инициализирована,..), но на самом деле с базой работать не мог. Устранили проблему (точно не помню как) или disconnect-ом после загрузки данных из базы в память в апаче-отце, или переносом этой части (коннект, загрузка данных в память) в функцию в модуле, которая стала вызываться не в отце, а в ребенке. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2004, 13:02 |
|
Распределенные транзакции / Совместное использование одной коннекции
|
|||
---|---|---|---|
#18+
> > не ожидал что проблема может возникнуть на более низком уровне > > - сокетов. А в чем здесь собственно грабли? > Я не знаю, есть ли здесь проблема, но судя по обсуждениям на > сайте постгреса, может оказаться. Для тех функций ядра системы, для которых нужна работа в существующей транзакции думаю проблем не будет, если явно не вызывать dbh->disconnect, так как именно эта ф-ия неявно вызывает закрытия сокета. Да, в любом случае нужно пробовать. Я думал, что кто- уже пробовал делать нечто подобное, и хотел услышать их мнение. > Или это противоречащие утверждения, или я чего-то недопонимаю. > Или вы описали две схемы - существующую и предполагаемую? Sorry for confuse. Да, это были описаны то что есть, и то что предполагается сделать. > > нужно передавать объект-хэдлер коннекции не только от > > интерфейсных программ, но и наоборот, возвращать от ядра вместе > > с результатами, так как в объекте должны меняться какие-то > > внутренние состояния? > Возможно. Но реально ли это? В общем, мне кажется, что "connect, fork" - > неправильный путь. Но может быть я ошибаюсь. Да, у меня сейчас в ядре выолняется fork, connect. А для _некоторых_ запросов нужно делать fork, don't_connect(использовать переданный $dbh, то о чем я говорил в первом посте). ... |
|||
:
Нравится:
Не нравится:
|
|||
09.05.2004, 12:05 |
|
Распределенные транзакции / Совместное использование одной коннекции
|
|||
---|---|---|---|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105.
Это та самая структура, которую нужно будет как-то в бинарном формате сохранять в проге, написанной на Perl и передавать в ядро системы, написанное на Си++. Кстате, я заметил, есть в этой структуре по крайней мере 2 "опасных" поля - указателя - inBuffer, outBuffer. Я так понимаю буфер выделяется в адресном пространстве процесса, который вызвал connect, а не где-то в АП самого Постгреса, и тогда все очень плохо(?) - из другого процесса (ядро моей системы) не удастся обращаться к ним. Вообще говоря, как проще из перла передать в Си-программу область памяти в данном конкретном случае. Не проще ли не возится с этим, а попробовать посмотреть в сторону библиотек, которые создают пул коннекций к постресу и при обращении отдают dbh уже подключенный к БД заранее. Это конечно, возможно, если среди них есть те, которые умеют работать с Перл- и Си-программами И опционально(должно переключаться неким ключиком при запросе) уметь отдавать dbh, которая уже распределена (отдана одним из предыдущих запросов и используется). Спасибо за ответы. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.05.2004, 14:27 |
|
|
start [/forum/search_topic.php?author=labirint&author_mode=last_topics&do_search=1]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
51ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
2ms |
others: | 729ms |
total: | 905ms |
0 / 0 |