powered by simpleCommunicator - 2.0.56     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Распределенные транзакции / Совместное использование одной коннекции
6 сообщений из 6, страница 1 из 1
Распределенные транзакции / Совместное использование одной коннекции
    #32510062
Wireless
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Доброго времени суток !

Господа, подскажите как можно решить такую проблему:

Имеется сложная система - интерфейс написан на mod_perl
скриптах, а ядро системы на С++, причем интерфейсные
скрипты часто вызывают функции ядра системы и в этих
функциях ядра требуется работа в той же транзакции, что
была начата в вызывающей программе.
Собственно, для этого необходимо передать одним из
параметров handler коннекции. Но достаточно ли этого?
Совместимы ли возвращаемые значения функции
perl[Pg.pm]::PQconnectdb и C[libpq]::PQsetdbLogin ?
На бинарном уровне или нужно будет писать какую-то
подпрограмму для преобразования полей этих объектов?
А достаточно ли вообще говоря передать объект,
описывающий коннекцию, чтобы в обычном режиме
продолжить выполнять команды в рамках транзакции,
которая начата в другом процессе/программе ?

С уважением.
...
Рейтинг: 0 / 0
Распределенные транзакции / Совместное использование одной коннекции
    #32510211
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Внутри c++ ядра или в perl-xs вы деалете fork? Если нет, то наверное проблем не должно быть, иначе не могу сказать, что вас может ожидать. Загляните в исходники DBD::Pg, в файле dbdimp.c подключение делается с помощью функции PQconnectdb().
...
Рейтинг: 0 / 0
Распределенные транзакции / Совместное использование одной коннекции
    #32510462
Wireless
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ок. Хорошо, то есть получается что эти значения абсолютно совместимы,
но не ожидал что проблема может возникнуть на более низком уровне -
сокетов. А в чем здесь собственно грабли? Ведь одновременно запросы
не будут идти от более чем одного процесса?

fork() делается только в Си-ядре, но коннекция у меня
вызывается в уже ответвленном дочернем процессе, не предполагается
работа с ним в родительском процессе. Единственная задача
одит. процесса - ответвлять потомков на каждый поступающий
запрос.

Спасибо за ссылку. Изучаю.

Кстате, по моему разумению нужно передавать объект-хэдлер
коннекции не только от интерфейсных программ, но и наоборот,
возвращать от ядра вместе с результатами, так как в объекте
должны меняться какие-то внутренние состояния? Правильно.

Спасибо за ответ.
...
Рейтинг: 0 / 0
Распределенные транзакции / Совместное использование одной коннекции
    #32510572
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
не ожидал что проблема может возникнуть на более низком уровне - сокетов. А в чем здесь собственно грабли?

Я не знаю, есть ли здесь проблема, но судя по обсуждениям на сайте постгреса, может оказаться.

в этих функциях ядра требуется работа в той же транзакции, что была начата в вызывающей программе

коннекция у меня вызывается в уже ответвленном дочернем процессе, не предполагается работа с ним в родительском процессе

Или это противоречащие утверждения, или я чего-то недопонимаю. Если в вызывающем процессе (ребенок апача с мод-перлом) был сделан коннект и начата транзакция (первая цитата), то как же "коннекция вызывается в уже ответвленном дочернем процессе"? Вы ведь не думаете, что можно сделать "connect, begin, update, disconnect", затем "connect, update, commit, disconnect" - и это будет одна транзакция? Или вы описали две схемы - существующую и предполагаемую? Разъясните пожалуйста.

нужно передавать объект-хэдлер коннекции не только от интерфейсных программ, но и наоборот, возвращать от ядра вместе с результатами, так как в объекте должны меняться какие-то внутренние состояния? Правильно.

Возможно. Но реально ли это? В общем, мне кажется, что "connect, fork" - неправильный путь. Но может быть я ошибаюсь.

P.S.: Когда-то натолкнулись на грабли. В одном из перловых модулей, загружаемых апачем-отцом при стартапе посредством PerlScript, создавался коннект к базе и загружались данные из базы в память. Затем каждый из форкнутых детей считал, что к базе он подключен (глобальная переменная $dbh в том модуле была определена, инициализирована,..), но на самом деле с базой работать не мог. Устранили проблему (точно не помню как) или disconnect-ом после загрузки данных из базы в память в апаче-отце, или переносом этой части (коннект, загрузка данных в память) в функцию в модуле, которая стала вызываться не в отце, а в ребенке.
...
Рейтинг: 0 / 0
Распределенные транзакции / Совместное использование одной коннекции
    #32511672
Wireless
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> > не ожидал что проблема может возникнуть на более низком уровне
> > - сокетов. А в чем здесь собственно грабли?

> Я не знаю, есть ли здесь проблема, но судя по обсуждениям на
> сайте постгреса, может оказаться.

Для тех функций ядра системы, для которых нужна работа в существующей
транзакции думаю проблем не будет, если явно не вызывать dbh->disconnect,
так как именно эта ф-ия неявно вызывает закрытия сокета. Да, в любом
случае нужно пробовать. Я думал, что кто- уже пробовал делать нечто
подобное, и хотел услышать их мнение.

> Или это противоречащие утверждения, или я чего-то недопонимаю.
> Или вы описали две схемы - существующую и предполагаемую?

Sorry for confuse. Да, это были описаны то что есть, и то что предполагается
сделать.

> > нужно передавать объект-хэдлер коннекции не только от
> > интерфейсных программ, но и наоборот, возвращать от ядра вместе
> > с результатами, так как в объекте должны меняться какие-то
> > внутренние состояния?

> Возможно. Но реально ли это? В общем, мне кажется, что "connect, fork" -
> неправильный путь. Но может быть я ошибаюсь.

Да, у меня сейчас в ядре выолняется fork, connect. А для _некоторых_
запросов нужно делать fork, don't_connect(использовать переданный
$dbh, то о чем я говорил в первом посте).
...
Рейтинг: 0 / 0
Распределенные транзакции / Совместное использование одной коннекции
    #32511705
Wireless
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: 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.
struct pg_conn
{
         /* Saved values of connection options */ 
        char       *pghost;                      /* the machine on which the server is
                                                                 * running */ 
        char       *pghostaddr;          /* the IPv4 address of the machine on
                                                                 * which the server is running
                                                                 * numbers-and-dots notation.
                                                                 * precedence over above. */ 
        char       *pgport;                      /* the server's communication port */ 
        char       *pgunixsocket;        /* the Unix-domain socket that the server
                                                                 * is listening on; if NULL, u
                                                                 * default constructed from pg
        char       *pgtty;                      /* tty on which the backend messages is
                                                                 * displayed (OBSOLETE, NOT US
        char       *connect_timeout;    /* connection timeout (numeric string) */ 
        char       *pgoptions;           /* options to start the backend with */ 
        char       *dbName;                      /* database name */ 
        char       *pguser;                      /* Postgres username and password, if any */ 
        char       *pgpass;
        char       *sslmode;             /* SSL mode (require,prefer,allow,disable) */ 

         /* Optional file to write trace info to */ 
        FILE       *Pfdebug;

         /* Callback procedures for notice message processing */ 
        PGNoticeHooks noticeHooks;

         /* Status indicators */ 
        ConnStatusType status;
        PGTransactionStatusType xactStatus;
         /* note: xactStatus never changes to ACTIVE */ 
        bool            nonblocking;     /* whether this connection is using
                                                                 * nonblock sending semantics
        bool            ext_query;              /* was our last query sent with extended
                                                                 * query protocol? */ 
        char            copy_is_binary;  /* 1 = copy binary, 0 = copy text */ 
        int                     copy_already_done;               /* # bytes already returned in
                                                                                 * COPY OUT */ 
        Dllist     *notifyList;          /* Notify msgs not yet handed to
                                                                 * application */ 

         /* Connection data */ 
        int                     sock;                    /* Unix FD for socket, -1 if not conne
        SockAddr        laddr;                  /* Local address */ 
        SockAddr        raddr;                   /* Remote address */ 
        ProtocolVersion pversion;        /* FE/BE protocol version in use */ 
        char            sversion[ 8 ];     /* The first few bytes of server version */ 

         /* Transient state needed while establishing connection */ 
        struct addrinfo *addrlist;       /* list of possible backend addresses */ 
        struct addrinfo *addr_cur;       /* the one currently being tried */ 
        int                     addrlist_family;         /* needed to know how to free addrlist
        PGSetenvStatusType setenv_state;        /* for 2.0 protocol only */ 
        const PQEnvironmentOption *next_eo;

         /* Miscellaneous stuff */ 
        int                     be_pid;                  /* PID of backend --- needed for cance
        int                     be_key;                 /* key of backend --- needed for cance
        char            md5Salt[4];             /* password salt received from backend */ 
        char            cryptSalt[ 2 ];    /* password salt received from backend */ 
        pgParameterStatus *pstatus;  /* ParameterStatus data */ 
        int                     client_encoding;         /* encoding id */ 
        PGVerbosity verbosity;           /* error/notice message verbosity */ 
        PGlobjfuncs *lobjfuncs;          /* private state for large-object access
                                                                 * fns */ 

         /* Buffer for data received from backend and not yet processed */ 
        char       *inBuffer;            /* currently allocated buffer */ 
        int                     inBufSize;               /* allocated size of buffer */ 
        int                     inStart;                 /* offset to first unconsumed data in
                                                                 * buffer */ 
        int                     inCursor;                /* next byte to tentatively consume */ 
        int                     inEnd;                   /* offset to first position after avai
                                                                 * data */ 

         /* Buffer for data not yet sent to backend */ 
        char       *outBuffer;           /* currently allocated buffer */ 
        int                     outBufSize;              /* allocated size of buffer */ 
        int                     outCount;                /* number of chars waiting in buffer *

        /* State for constructing messages in outBuffer */ 
        int                     outMsgStart;     /* offset to msg start (length word); if
                                                                 * -1, msg has no length word
        int                     outMsgEnd;              /* offset to msg end (so far) */ 

         /* Status for asynchronous result construction */ 
        PGresult   *result;                      /* result being constructed */ 
        PGresAttValue *curTuple;         /* tuple currently being read */ 

#ifdef USE_SSL
        bool            allow_ssl_try;   /* Allowed to try SSL negotiation */ 
        bool            wait_ssl_try;    /* Delay SSL negotiation until after
                                                                 * attempting normal connectio
        SSL                *ssl;                        /* SSL status, if have SSL connection
        X509       *peer;                       /* X509 cert of server */ 
        char            peer_dn[ 256  +  1 ];                /* peer distinguished name */ 
        char            peer_cn[SM_USER +  1 ];    /* peer common name */ 
#endif

         /* Buffer for current error message */ 
        PQExpBufferData errorMessage;            /* expansible string */ 

         /* Buffer for receiving various parts of messages */ 
        PQExpBufferData workBuffer;  /* expansible string */ 
};

Это та самая структура, которую нужно будет как-то в бинарном формате
сохранять в проге, написанной на Perl и передавать в ядро системы,
написанное на Си++.

Кстате, я заметил, есть в этой структуре по крайней мере 2 "опасных"
поля - указателя - inBuffer, outBuffer. Я так понимаю буфер выделяется
в адресном пространстве процесса, который вызвал connect,
а не где-то в АП самого Постгреса, и тогда
все очень плохо(?) - из другого процесса (ядро моей системы) не удастся
обращаться к ним.

Вообще говоря, как проще из перла передать в Си-программу
область памяти в данном конкретном случае. Не проще ли не возится с
этим, а попробовать посмотреть в сторону библиотек, которые
создают пул коннекций к постресу и при обращении отдают dbh
уже подключенный к БД заранее. Это конечно, возможно, если среди
них есть те, которые умеют работать с Перл- и Си-программами
И опционально(должно переключаться неким ключиком при запросе)
уметь отдавать dbh, которая уже распределена (отдана одним из
предыдущих запросов и используется).

Спасибо за ответы.
...
Рейтинг: 0 / 0
6 сообщений из 6, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Распределенные транзакции / Совместное использование одной коннекции
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]