I know there is a module like Apache::DBI which allows to use persistent connections to database under mod_perl.
Is there an easy way to make something like this? Could you recommend any memcached pooling package?
If you look at Apache::DBI's source code, you'll see that it just puts the database handle in a lexical scoped at the top of the package. It's easy enough to do this for Memcached. Make a new package, with a my $memcached; at the top, then have an init() method make the connection and save it in that lexical. Then have a getConnection() method to fetch the connection in your code. That method needs to check if the connection is still alive and reconnect if needed.
Lastly, setup a PerlChildInitHandler to call init() (see Apache::DBI connect_on_init()).
Related
I'm using an Autofac container for the entire lifetime of my application, but I want to dispose the components myself.
I.E if I have builder.RegisterType<SomeType>(), I don't want the container to keep references of SomeType which will keep those alive even if not referenced anywhere else (if RegisterInstance is used OTOH, then of course the container must keep a reference to the singleton).
I can see that I can do builder.RegisterType<SomeType>().ExternallyOwned() which solves my problem for one type, but I don't want to write it for every type, and more importantly I also use builder.RegisterSource(new AnyConcreteTypeNotAlreadyRegisteredSource()); which doesn't give me the option of using ExternallyOwned.
Is there a way to specify "ExternallyOwned" for the entire container? Or, to put it another way, tell the container to disable the entire dispose feature and not keep references for objects it doesn't need?
There is not a way to disable container disposal services. You might try to hook in with something like the logging module but I could see that not working 100% and missing edge cases of you're not careful.
Automatic tracking and disposal is a pretty common container feature. I'd recommend instead of fighting it you refactor your code to embrace it. It'll make life a lot easier.
I would like to share a blessed object between two or more Perl applications. The object in question is quite expensive to instantiate, but always the same (static). The idea is to instantiate it once in one application and use it in other applications. This particular object is basically an http client using HTTP::Tiny an a whole bunch of other modules. Instantiating it via new() can take more than 50% of the total run time. I think the only module which may be a problem is the HTTP::Tiny since it open sockets, but not really sure. Can I use IPC::Shareable or some other method to share this http client among other applications?
Follow-up, are there any significant security issues with IPC::Shareable?
It supports anything Storable can handle. So it can handle objects, but not file handles (incl sockets). File handles are process-specific anyway.
Access to the shared memory is controlled using the same permission system that is used to control access to files (via the mode option), so the security issues are the same as they are for files.
Connection pooling is a new concept for me. I am working with a desktop application and using single database for this application.
Then i want to know that can i use connection pooling in my application to increase speed constraint.
Thanks in advance....
Initializing and destroying connections repeatedly is costly. Instead, what you may do is use a pool of connections. You initialize a collection of connections at the initialization phase of your application, and destroy it at the end. This way, each connection is only initialized and destroyed once.
Later on you can play around with other attributes of the pool, like whether its size stays fixed, or changes to meed demand, whether or not it is thread-safe, its size, etc. These should all be tuned for your specific application and specific needs.
I am a little confused on how to go about and do this....
On each page of my app i connect to PHP file to drag in data from my server. I have about 10 pages. Now if there is no connection to the internet then of course now data can be received.
Often the app crashes and we are putting this down to not having the data due to a change in connection or wifi whatever.
Now i have setup the reachability thing and that works, but i dont know how to link this in with the PHP calls. Should i check the reachability and if no connection then dont run the call. If so, what about all the variables, they will still be null and cause an error then?
I dont really know what is the best solution.
Hope you can help
Alex
Are the php calls just to receive data from a database without using a built in DB framework such as SQLite? If so, I went the same route to avoid the headache at first, but running SQLite in your app is a better solution overall, and reduces multiple dependencies (such as internet connection).
Now if the php calls that give you data back are receiving this information from yet another source and then feeding it into its own DB.....
Should i check the reachability and if no connection then dont run the call
Yes you should. This is done in multiple apps already. What variables would be null in this case? Pop the code that makes the call in an "if" block below this check, and only run it if true. Error handling other variables that might be null because the php call isn't setting them is up to you. You can do this is multiple ways.
You should certainly cache the data so the App doesn't HAVE to connect to the internet to display something, other than that I would make sure to use asynchronous requests and the timeout feature of NSURLRequest to control your attempts to request data in the background. If you don't get the data, just keep using what you have cached.
Can you please give some suggestions on sqlite using on the iPhone?
Within my application, I use a sqlite DB to store all local data. Two methods can be used to retrieve those data during running time.
1, Load all the data into memory at initialization stage. (More memory used, less DB open/close operation needed)
2, Read corresponding records when necessary, free the occupied memory after using. (Good habit for memory using, but much DB open/close operations needs).
I prefer to use method 2, but not sure whether too many DB opening/closing operations could affect app's efficiency. Or do you think I can 'upgrade' method 2 by opening DB when app launches and closing DB when app quits?
Thanks for your suggestions very much!
First of all: use FMDB to access SQLite!
Then, create your own singleton "MyDB" class.
Every time you need the database, you do [MyDB instance] to get your FMDB instance.
That way you only have one DB open (in didFinishLaunching) an you close it when your app exits.
That's far and away the best way to use SQLite on the iPhone.
The other option is to use CoreData, something I find great for when you start with an empty database, but FMDB/SQLite works best for me if I have a set of data that's read-only.
Apple seems to suggest that you avoid preloading all the data during the startup in order to ensure faster and smoother startup. Supposedly you should only load data when/if the user needs it.