Hi Anjana,

Few minutes ago I recreated the scenario. Then I reverted um.core to use
dbcp pooling and now it works perfectly.

I know ndatasource is fantastic! But looks like there are some issues with
it.

This would be a blocker for our kernel release. Can we use a newer version
of ndatasource?

thanks,
dimuthu

On Wed, Jul 4, 2012 at 9:32 PM, Sumedha Rubasinghe <[email protected]> wrote:

> Dimuthu,
> Can you confirm if the same method is being used in following thread
> started by Shelan as well.
> '[Dev] Cannot log into product after creating Tennants'.
>
>
>
> On Wed, Jul 4, 2012 at 6:02 PM, Dimuthu Leelarathne <[email protected]>wrote:
>
>> Hi all,
>>
>>
>> This is a connection pooling issue. The reason for saying that is as
>> follows.
>> Here is the SQL = String sql = "SELECT UM_ID FROM UM_TENANT WHERE
>> UM_DOMAIN_NAME=?"
>>
>> Consider the following control flow.
>>
>> Control Flow
>> ===========
>>
>> Connection dbConnection1 = getDBConnection();
>> Connection dbConnection2 = getDBConnection();
>> prepare and execute SQL using dbConnection2 -> result is successful
>> prepare and execute SQL using dbConnection1 -> result is unsuccessful
>> prepare and execute SQL using dbConnection2 -> result is successful
>> prepare and execute SQL using dbConnection1 -> result is unsuccessful
>>
>> Now see we are executing the same SQL using same parameter using two db
>> connection. The dbConnection1 goes totally crazy for requests that hit the
>> above code segment - one after the other.
>>
>> thanks,
>> dimuthu
>>
>>
>>
>>
>> On Wed, Jul 4, 2012 at 4:44 PM, Dimuthu Leelarathne <[email protected]>wrote:
>>
>>> Hi Sumedha,
>>>
>>> This is not an application level concurrency issue because how would you
>>> explain,
>>>
>>> 1) With mysql_workbench while I have paused the program with a debug
>>> point.
>>> 2) There is concurrency associated with this scenario
>>> 3) The reverse works. When domain is given the ID is retrieved
>>>
>>> My next steps,
>>> 1) Run using h2 server
>>> 2) Retrieve domain given the ID using same db connection
>>>
>>> thanks,
>>> dimuthu
>>>
>>>
>>> On Wed, Jul 4, 2012 at 4:11 PM, Sumedha Rubasinghe <[email protected]>wrote:
>>>
>>>> Dimuthu,
>>>> I was under the impression this was solved. Thought Anjana had a look @
>>>> it.
>>>> This cannot be a caching issue @ the database level. Then it should
>>>> impact everywhere. I still feel this is an application level concurrency
>>>> issue.
>>>>
>>>> Let me discuss with Anjana & get back to you. Sorry for allowing you to
>>>> live with this for long.
>>>>
>>>> On Wed, Jul 4, 2012 at 3:56 PM, Dimuthu Leelarathne 
>>>> <[email protected]>wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> This seems to be a blocker for us. Looks like a caching issue at mysql
>>>>> and/or pooling layer.  I tried without the following indexing and still 
>>>>> get
>>>>> the same results. I don't think it is a mysql layer because the same SQL 
>>>>> is
>>>>> running on mysql_workbench.
>>>>>
>>>>> CREATE UNIQUE INDEX INDEX_UM_TENANT_UM_DOMAIN_NAME
>>>>>                     ON UM_TENANT (UM_DOMAIN_NAME);
>>>>>
>>>>> thanks,
>>>>> dimuthu
>>>>>
>>>>>
>>>>> On Mon, Jul 2, 2012 at 12:51 PM, Dimuthu Leelarathne <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> AppFactory setup done last hour shows the same error again.
>>>>>>
>>>>>> thanks,
>>>>>> dimuthu
>>>>>>
>>>>>>
>>>>>> On Thu, Jun 28, 2012 at 7:44 PM, Dimuthu Leelarathne <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I believe what is happening is AppFactory is trying to read the
>>>>>>> uncommitted data from the db. The attached screenshot explains the 
>>>>>>> scenario
>>>>>>> nicely. I kept adding test1,test2,test3 .... test8 and out of these only
>>>>>>> even numbers are actually added - odd ones are failing.
>>>>>>>
>>>>>>> But after that I stopped the server did a "select *" before doing
>>>>>>> the "select UM_ID from where *"  in user.core. Then replaced the jar and
>>>>>>> restarted the server. As you can see test9, test10, test11 and test12 
>>>>>>> are
>>>>>>> added without any issue at all. Meaning doing a "select *" somehow 
>>>>>>> forced
>>>>>>> "select UM_ID from where *" to work correctly. Looks like we are doing 
>>>>>>> some
>>>>>>> dirty reads.
>>>>>>>
>>>>>>> thanks,
>>>>>>> dimuthu
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jun 28, 2012 at 5:37 PM, Dimuthu Leelarathne <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> This is fun. I am wondering whether I should a screen recording of
>>>>>>>> this event.
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>> dimuthu
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> /sumedha
>>>> +94 773017743
>>>>
>>>
>>>
>>
>
>
> --
> /sumedha
> +94 773017743
>
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to