Problem using pstore with multi-users

Hi all,
when i'm using pstore with multi-users:
Permission denied - ../comments.dat.new
it seems that more then one user is asking to use the same file.
i tried to use synchronize for locking the transaction until it finsh,
but it seems that i can not using it when i using pstore.
any one having any idea???
Thanks.

···

--
Posted via http://www.ruby-forum.com/.

pstore doesn't itself do any locking of any sort.

If you have multiple threads or processes that might try to use pstore on the same file at the same time, you will have to handle the locking yourself.

If you aren't on Windows, I suggest Ara Howard's lockfile.rb if you are doing multiprocess work. If it is multithreaded, you certainly can use a mutex to synchronize access.

http://codeforpeople.com/lib/ruby/lockfile/

However, permission denied suggests a simple file permissions problem that locking will not solve, so I suggest you take a look at whether you might accidentally be be creating the pstore file under a user or with permissions that you don't intend.

Kirk Haines

···

On Wed, 30 Aug 2006, Noam Noam wrote:

Hi all,
when i'm using pstore with multi-users:
Permission denied - ../comments.dat.new
it seems that more then one user is asking to use the same file.
i tried to use synchronize for locking the transaction until it finsh,
but it seems that i can not using it when i using pstore.
any one having any idea???
Thanks.

thanks Kirk,
i didn't understand what do you meen by "under a user "
how can i solve this problem?
the output error "premisson denied" pops up from some of the threads
(randomally) and not from all of them, so i figured its because to many
threads attemps to write to the pstore file in the same time, isn't it?
Thanks again,
Noam

unknown wrote:

···

On Wed, 30 Aug 2006, Noam Noam wrote:

Hi all,
when i'm using pstore with multi-users:
Permission denied - ../comments.dat.new
it seems that more then one user is asking to use the same file.
i tried to use synchronize for locking the transaction until it finsh,
but it seems that i can not using it when i using pstore.
any one having any idea???
Thanks.

pstore doesn't itself do any locking of any sort.

If you have multiple threads or processes that might try to use pstore
on
the same file at the same time, you will have to handle the locking
yourself.

If you aren't on Windows, I suggest Ara Howard's lockfile.rb if you are
doing multiprocess work. If it is multithreaded, you certainly can use
a
mutex to synchronize access.

http://codeforpeople.com/lib/ruby/lockfile/

However, permission denied suggests a simple file permissions problem
that
locking will not solve, so I suggest you take a look at whether you
might
accidentally be be creating the pstore file under a user or with
permissions that you don't intend.

Kirk Haines

--
Posted via http://www.ruby-forum.com/.

I don't think that's accurate. Here's part of the transaction() method for PStore. Note the calls to flock():

   def transaction(read_only=false) # :yields: pstore
     # ...

       unless read_only
         file = File.open(@filename, File::RDWR | File::CREAT)
         file.binmode
         file.flock(File::LOCK_EX)
         commit_new(file) if FileTest.exist?(new_file)
         content = file.read()
       else
         begin
           file = File.open(@filename, File::RDONLY)
           file.binmode
           file.flock(File::LOCK_SH)
           content = (File.read(new_file) rescue file.read())
         rescue Errno::ENOENT
           content = ""
         end
       end

    # ...

James Edward Gray II

···

On Aug 30, 2006, at 7:38 AM, khaines@enigo.com wrote:

On Wed, 30 Aug 2006, Noam Noam wrote:

Hi all,
when i'm using pstore with multi-users:
Permission denied - ../comments.dat.new
it seems that more then one user is asking to use the same file.
i tried to use synchronize for locking the transaction until it finsh,
but it seems that i can not using it when i using pstore.
any one having any idea???
Thanks.

pstore doesn't itself do any locking of any sort.

Well now, that's really interesting, because I never had anything but misery when I tried using pstore in a context where two threads or processes would try to access the same file at the same time. This has me very curious as to why.

Fiddlesticks!

Kirk Haines

···

On Thu, 31 Aug 2006, James Edward Gray II wrote:

pstore doesn't itself do any locking of any sort.

I don't think that's accurate. Here's part of the transaction() method for PStore. Note the calls to flock():

def transaction(read_only=false) # :yields: pstore
   # ...

     unless read_only
       file = File.open(@filename, File::RDWR | File::CREAT)
       file.binmode
       file.flock(File::LOCK_EX)
       commit_new(file) if FileTest.exist?(new_file)
       content = file.read()
     else
       begin
         file = File.open(@filename, File::RDONLY)
         file.binmode
         file.flock(File::LOCK_SH)
         content = (File.read(new_file) rescue file.read())
       rescue Errno::ENOENT
         content = ""
       end
     end

Noam Noam, you might find this useful, if you have multiple threads in a process:

http://raa.ruby-lang.org/project/fsdb/

···

--
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

James Gray wrote:

···

On Aug 30, 2006, at 7:38 AM, khaines@enigo.com wrote:

Thanks.

pstore doesn't itself do any locking of any sort.

I don't think that's accurate. Here's part of the transaction()
method for PStore. Note the calls to flock():

so, if i understand correctly, because in pstore.rb there is a lock to
the file, i cannot use pstore with some processes because it will front
a lock. and because of that i get "premission denied"???
thanks you all, for your all responses.

--
Posted via http://www.ruby-forum.com/.

khaines@enigo.com wrote:

Well now, that's really interesting, because I never had anything but misery when I tried using pstore in a context where two threads or processes would try to access the same file at the same time. This has me very curious as to why.

In the case of threads you might have had misery because PStore doesn't do any thread-level locking (e.g. Mutex or Sync). But PStore should be safe at the process level, AFAIK.

···

--
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

Noam Noam wrote:

so, if i understand correctly, because in pstore.rb there is a lock to the file, i cannot use pstore with some processes because it will front a lock. and because of that i get "premission denied"???
thanks you all, for your all responses.

Seems so. s/pstore/sqlite/ maybe? A single-table, string -> blob database isn't SUCH a horrible conceptual rape for simple apps. (Or as some system architects of my days past would think, not even for embedded J2EE.)

David Vallner

it is - just not on nfs. i use it this way quite a bit with zero issues.
it's really nice as the backend for tiny cgi scripts.

-a

···

On Thu, 31 Aug 2006, Joel VanderWerf wrote:

khaines@enigo.com wrote:

Well now, that's really interesting, because I never had anything but
misery when I tried using pstore in a context where two threads or
processes would try to access the same file at the same time. This has me
very curious as to why.

In the case of threads you might have had misery because PStore doesn't do
any thread-level locking (e.g. Mutex or Sync). But PStore should be safe at
the process level, AFAIK.

--
what science finds to be nonexistent, we must accept as nonexistent; but what
science merely does not find is a completely different matter... it is quite
clear that there are many, many mysterious things.
- h.h. the 14th dalai lama

Hi all,
after more examination of the fails,
its look like pstore.rb fail in line #179
File.unlink(new_file)

any one have an idea' whats the problem???

Thanks again,
Noam.

···

--
Posted via http://www.ruby-forum.com/.

Noam Noam wrote:

Hi all,
after more examination of the fails,
its look like pstore.rb fail in line #179
File.unlink(new_file)

any one have an idea' whats the problem???

I think you can't delete a file in use. (unlink == delete)

So the problem is what others have already mentioned, it's a lock file or something that prevents another process from thrashing the storage file while you're reading from it.

David Vallner