in reply to atomic tie?

perl is a serial process. If your getting a race condition, it's between 2 or more forked perl processes; which leads to another issue of forking and database handles; this can be very dangerous - particularly when it comes to SQLite. Also, you incrementing a key also in that environment is also very risky. If you want to avoid collisions and not change your set up, you need to look at generating some kind of globally unique identifier or checksum of the data record you're adding. You need to let the esteemed monks know what you're doing.

Replies are listed 'Best First'.
Re^2: atomic tie?
by ikegami (Patriarch) on Aug 24, 2024 at 03:09 UTC

    perl is a serial process.

    Have you not heard of threads, coros and signal handlers? (There are surely others.)

[reply]
      Yes, but perl itself is fundamentally a single process. All that other stuff is to avoid the inherent lack of thread safety. I understand it was never meant to be thread safe, so don't take that as a criticism.
[reply]
[d/l]

        Yes, but perl itself is fundamentally a single process.

        What does that mean??? What does that have to do with anything???

        You said "If your getting a race condition, it's between 2 or more forked perl processes". This is clearly wrong. At so many levels.

        Even if Perl was single process and single threaded and didn't have coros and didn't have signals and didn't have async IO and ... Even if all that, a race condition is still possible. The OP is talking about a database, so there could be a race with other users of the database!

[reply]

In Section Seekers of Perl Wisdom