Mark, thanks for your response. No, I'm not doing any internet lookups. The main time consuming parts of the processing would be reading and possibly writing to the app's SQLlite database. I expect that in the vast majority of cases the processing time would be of the order you mentioned (around 250ms), maybe slightly more if a write was needed to save the message.
It is potential database concurrency issues that might occasionally result in delays in the SMS receiver. If the user performs an action that results in say 500 inserts or updates to the app database, I was assuming that these updates would be performed within the same transaction, thereby creating an exclusive lock the database for the duration. If each update takes 30ms, thats 15 seconds total. During this time other components (like the SMS receiver) would block when attempting to read the database. Perhaps I just need to craft my database update services to minimise the likelihood of long-running transactions, breaking them up where possible to minimise concurrency issues. Then I could do the required database calls in my broadcast receiver on the assumption that any blocking will only be for short durations (say 1 second or less). I'll do some further analysis to check that this will be a viable approach. Thanks again. Steve -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
