Jonathan Leffler wrote:
> CHEN SEI-LIM wrote:
>
> > Jonathan Leffler wrote:
> >
> > > CHEN SEI-LIM wrote:
> > >
> > > > You can make a simple program to try it not only your supposition.
> > > > If I am wrong I will say sorry to everybody.
> > >
> > > Since you're so adamant that it can be done, perhaps you'd care to show us the
> > > code that allows it to work; then you won't have to apologize to anybody. In
> > > the first instance, I'm not actually going to be fussed about whether your code
> > > is o/s independent or DBMS independent - let's see one working example for
> > > Oracle, or Informix, or DB2, or Sybase. If you have none of these, then perhaps
> > > you'd reveal which database(s) you know it can be made to work with -- I presume
> > > you have actually done this at least once and probably many times, so it won't
> > > be particularly difficult for you to do.
> >
> > In UNIX, child inherit every thing from parent but PID after forking.
> > The same stack, heap, text, and file discriptors.
>
> In POSIX.1-1990 (which is what I have at home; I keep the 1996 standard at work),
> there are 8 items that are different between the child and the parent:
>
> 1. The child process has a unique process ID. The child's PID also does not match
> any active process group ID.
>
> 2. The child process has a different parent process ID (which is the process ID of
> the parent process).
>
> 3. The child process has its own copy of the parent's file descriptors. Each of
> the childs file descriptors refers to the the same open file description with the
> corresponding file descriptor of the parent.
>
> [JL notes: I believe that the significance of this is that if the child reads on a
> file, it does not move the parent processes current read position, or vice versa, but
> that concept really only applies to regular files and block devices. Sockets, some
> character devices, pipes and FIFOs have different properties; in particular, if
> process A reads a byte from a socket, process B can't read that same byte (whereas in
> a regular file or a block device, process B can read the same byte that process A
> got.]
>
If the file position moved after each child reading is only your guess.
I suggest you had better try it actually. Try it then I will tell you why.
And in character devices, with some special paramter setup I can keep the same byte in
kernel buffer
for another reading. It is not so difficult.
>
> 4. The child process has its own copy of the parent's open directory streams.
>
> 5. The child process's values of tms_utime, tms_stime, tms_cutime and tms_cstime
> are set to zero.
>
> 6. File locks previously set by the parent are not inherited by the child.
>
> 7. Pending alarms are cleared for the child process.
>
> 8. The set of signal pending for the child process is initialized to the empty
>set.
>
> I'm pretty sure that there are a whole bunch of extra small details that are
>different
> in the current POSIX.1-1996 standard.
>
> Granted, that does not mean that sockets etc won't also work, but sockets aren't the
> only way of communicating with database servers. Informix also supports a shared
> memory connection method, and a stream pipe method, and on some platforms it uses TLI
> in preference to sockets, and there are, or used to be, some other exotic protocols,
> and SE uses plain old unamed pipes, in general. AFAIK, the shared memory method also
> uses a semaphore (and semaphores are one of the things in POSIX.1-1996 that will be
> different in the child and the parent). Even that may not be crippling.
>
First, I have to say - UNIX is the only OS I indicating, and I don't know what is TLI
or
SE?
Second, using shared memory may be a good idea for system administrating.
But it can not support remote access. If you want to access database from another host,
socket is the best way, isn't it?
Third, System V IPC is not convenient for UNIX programmer. In new systems we do not
use it
any more.
And System V Semaphore is also not a good method to handle concurrency.
Last, System V stream pipe is almost the same as socket, FIFO.
>
> Further, and more seriously, if both the child and the parent write a message to the
> socket, then both will hang waiting to read the response on the socket, and there's
>no
> guarantee that the 'correct' process will read the correct answer. Especially if the
> answers are not a single packet. The Unix scheduler does not guarantee that you'll
> repeatedly wake only the process that happens to be waiting for the right part of the
> response -- it'll wake any process that happens to be waiting to read any response.
"scheduler"? Oh, you are talking about "scheduler". Do you really know what's
"scheduler"?
I don't know what's "scheduler", I only know "mutex handle" can guarantee my guarantee.
If you are interested in it I can mail you lots of information by charging.
>
> Further still, if the two processes happened to create statements with the same name
> (because at least in Informix, each SELECT statement gets given a name, and the name
> generator is not safe between multiple processes sharing a single connection -- it's
> fine for multiple processes with their own connections), then the parent will create
>a
> statement number ix_007, and then the child process might create statement ix_007,
>and
> then when the parent gets to execute ix_007, it will actually be the child's
> statement, not its own. The chances are it won't work very well. If you're really
> unlucky, it might be the difference between UPDATE SomeTable SET flag = 1 WHERE
> key_value = ? and DELETE FROM SomeTable WHERE key_value > ?, and all hell breaks
>loose
> when the wrong data is deleted. Funny, database folks tend to get antsy when data
> goes missing unexpectedly. Especially since users tend to be careless about using
> AutoCommit and about checking the number of rows affected by a statement (though if
> AutoCommit is On, it doesn't help you to know that you operated on 3000 rows instead
> of 1 -- the transaction has been committed).
>
> So, sure, you can communicate with the database server down the same socket. But,
> unless you go through the overhead of ensuring that the two processes are not trying
> to use it concurrently, you don't know whether you are going to get coherent answers.
> And the overhead of ensuring that the two processes are not trying to use it
> concurrently would be far higher than the overhead of simply setting up to
>independent
> connections.
>
If Informix can handle a query via statement number like ix_007.
First, you have to transmit the SQL string into Informix previously.
After it, Informix return the statement number back to you for identification.
Those statements numbers should be generated by database engine.
It is unreasonable to name statements numbers in your program.
If Informix is degined as you say. It really is not a good database.
Another thing about the system loading with mutex handle, I have to say.
No, you are wrong. A simple exclusive lock does not take overhead.
>
> > If every query was transmitted via socket from client library to database engine.
> > Why it can not work? Can you tell me why?
> > So it is the reason I suppose processes can sharing $dbh.
> > But why Oracle, or Informix, or DB2, or Sybase do not support $dbh sharing?
>
> Because, in general, two processes want to do their own queries at their own rates,
> without having to ask the other "do you mind if I start a transaction now", or "do
>you
> mind if I do a rollback now". Even assuming you managed to get the communications
> issues resolved, the single connection can only have a single transaction open at a
> time, so both the changes made by the child and those made by the parent will be in
> each others transactions - doubly an issue if AutoCommit has to be simulated by
> explicitly adding a COMMIT after each statement. Basically, it doesn't make sense to
> try it, unless you have a very much more restricted set of semantics than is usual.
> If the parent process will go to sleep until after the child finishes, then maybe
> you'd stand a chance; except, of course, that when the child terminates, the
> connection will be cleaned up, and when the connection is cleaned up in the child,
>the
> database engine will think that the connection is no longer valid, and will object
> mightily to the parent trying to use a non-existent connection. The problems go on,
> and on, and on.
>
1. "at their own rates"?
You can make a simple statistics. How often does your program execute query?
2. "transaction"?
I do not trust their transaction or rollback. So I always handle it in my program.
3. And what is the condition you need "transaction"?
You have no ability to develop an on-line trading system yet.
> > Maybe they really do not want anybody can do it by their business concern.
>
> No, it's simpler than that. They want people to get reliable results from using their
> products.
>
> There are also licencing issues -- all the world is not Open Source -- but I'm
> primarily concerned with the technical results of abusing the connection, not with
>the
> legal problems you get into.
You are talking about technique with me? Are you sure?
You do not have enough background knowledge to talk about it.
>
> Anyway, if you are happy to try it, and then to accept any errors that occur, that's
> fine by me. It's your database, and your problem. You were warned that it was not a
> particularly good idea. For some reason that currently escapes me, I've detailed
> quite a number of reasons why it is not a good idea. I don't think any of the formal
> reasons given are completely specific to Informix -- issues like statement names and
> controlling who gets woken to read the data and so on are likely to be common to all
> multi-process database systems. The issue of locks being lost across a fork() is apt
> to be traumatic for single-process database systems (I want to say embedded
>databases,
> but it has the wrong connotations).
>
> And, finally, the DBI documents that it is not supported and not reliable. What more
> do you need to know about it?
>
Your are in a jail made by INFORMIX.
If everybody all like you space travel would never come true.
Open your mind, you will gain more.
>
> --
> Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED])
> Guardian of DBD::Informix 1.00.PC1 -- see http://www.cpan.org/
> #include <disclaimer.h>
