Oooh boy ... I've been working on a SMS gateway some time now - which I intend to open up to the public in early february - but I bounce against a wall for the moment.
The problem ... concurrent access to a database (sqlite). I looked into the DBD::SQLite code and it does implement the CLONE method. I wonder ... what else can I do to get this DB multithreaded?
For the moment I have 3 types of threads. An incoming SMS handler, some request handling threads and an embedded webserver thread for the web based UI. All three use the DBD::SQLite via Class::DBI to store application data. All went fine until I added a table to communicate status from the components to the UI. My first implementation did not use a DB for this, but classes could subscribe themselves to a singleton status object and the UI thread could query the singleton, which would delegate the status method to all registered objects ... but ... that does not work, as 'complex' variables can not be shared in Perl threads. So I reverted to a database in which objects 'put' status information in a timely fashion ... not as clean as the subscribe/query principle, but at least it should work.
Well ... my plan is to look into DBD::SQLite and try to get it multi threaded ...
And ... in the end ... I wonder if Perl is fit to develop this type of applications in, with this type of application architecture (multi threaded). I deem it too javaesque ... I better could have used POE or use forking. I'm not sure if it will fit POE, but it surely will fit a forking strategy and it should not take too much time to do so ...
Johan
