The forum will experience an outage sometime between February 10 at 7:00pm EST and February 12 at 11:59 EST for installation of security updates. The actual time and duration of the outage are unknown but attempts will be made to minimize the downtime. We apologize for any inconvenience.

Ultralite C++ API documentation mentions: "If an application requires multiple threads accessing the UltraLite database, each thread requires a separate connection". But I´ve found nothing about multi-threading in UltraliteJ documentation and my tests do not fail when accessing the same connection through different threads.

I want to access (execute SELECT statements) the same UL connection in many concurrent threads in a Ultralite Android application, is it safe?

asked 10 Jan '12, 10:07

Ericsen%20Cioffi's gravatar image

Ericsen Cioffi
accept rate: 0%

We do not recommend the concurrent use of connections. While individual API calls will behave correctly, conncurrent calls will mess up error tracking or cursor positions. UltraLiteJ for Android uses the C++ UltraLite under the covers and even for UltraLiteJ we do not recommend concurrent use of Connections.

You can can create a connection in on thread and "pass it" to another.

permanent link

answered 10 Jan '12, 10:19

PhilippeBertrand%20_SAP_'s gravatar image

accept rate: 22%

According to your answer, if I guarantee that API calls in different threads will not be concurrent (by implementing a mutex control) everything will work fine, right?

(10 Jan '12, 11:09) Ericsen Cioffi
Replies hidden

The reason why you did not see any issue is that you may have been using the very narrow scenario that lets you get away with it. If you are doing just selects of read only statements, not sharing prepared statements or result sets, you could get away with a connection for all the selects and not see any errors. You would want to use say a second connection (reserving the first for insert, update operations). Again, this is not recommended.

Since you are not sharing prepared statements and result sets, why share the connection? Use the maximum threading you can.

There is already a mutex for the library so adding another around a group of API calls sort of defeats the purpose of having multithreading.

If you are trying to keep the UI thread responsive, one can have a worker thread and queues up stuff for it.

(10 Jan '12, 13:18) PhilippeBert...

I want to share connections because my application use many threads. I can´t open one connection to each thread because there is a limit of 14 UL connections. But, I understand your point. I´m going to change my application to follow your recomendation. Thank you!

(10 Jan '12, 14:29) Ericsen Cioffi
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 10 Jan '12, 10:07

question was seen: 2,936 times

last updated: 10 Jan '12, 14:29