Well, you can always synchronize access and share the same pointer,
right (in windows; using fork in unix is bad, presumably because fork()
just copies all the data into the child)?
It sucks if you are using sql_step, or, I imagine, precompiled queries,
though.
--Keith
******************************************************
- I'm not a professional; I just get paid to do this.
- Things I've learned about multithreaded programming:
123... PPArrvooottieedcc ttm ueelvvteeirrtyyhtt
rhheiianndgge dwi hnpi rctohhg eri aslm omscitanalgt
iowcbh,je engceltvo ebwrah lip,co hso srci abonlt ehb
.ee^Nr waicscee snsoetd 'aotb jtehcet -slaomcea lt'il
m^Ne from two or more threads
******************************************************
-----Original Message-----
From: Darren Duncan [mailto:[EMAIL PROTECTED]
Sent: Friday, October 08, 2004 4:23 PM
To: [EMAIL PROTECTED]
Subject: RE: [sqlite] still having problems with DBD::SQLite2
At 4:28 PM -0500 10/8/04, Freeman, Michael wrote:
>I am pretty sure I know whats going on now. I am using POE (Perl Object
>environment, I highly recommend it poe.perl.org) and what is happening
>is my program is basically trying to do inserts into the database at
>the same time, which I think is creating a deadlock. It can handle
>doing one insert at one time, but when I fire a lot of events at it
>that are kind of happening asynchronously on the server, it fails. It
>would be nice if the debugging and logging output made some sort of
>damn sense or would tell you these things.. I think I have had my head
>up my ass all day cuz of this. I am going to try do some stuff in my
>program that will "pause" all the other helper "threads" when I'm doing
>a sql insert.
Make sure that each thread has its own database connection via its
own DBI->connect(), assuming that DBI isn't pooling and reusing the
connections behind your back. This is analagous to C programs having
a separate sqlite open() in each thread, which is necessary. --
Darren Duncan
