[security-dev] concurrent access to IDM

[Anil Saldhana]

Hi Bill,
  look at the picketlink-* quickstarts at 
https://github.com/jboss-jdf/jboss-as-quickstart

I don't think there is a need to begin/end entity manager transactions 
by the apps. It should be taken care of by the container.

Eg:
https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/picketlink-authorization-idm-jpa/src/main/resources/META-INF/persistence.xml
https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/picketlink-authorization-idm-jpa/src/main/java/org/jboss/as/quickstarts/picketlink/authorization/idm/jpa/IDMConfiguration.java
https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/picketlink-authorization-idm-jpa/src/main/java/org/jboss/as/quickstarts/picketlink/authorization/idm/jpa/IDMInitializer.java

Regards,
Anil

On 06/21/2013 03:39 PM, Bill Burke wrote:
> One problem I've seen that I emailed before is that the JPA
> IdentityStore requires application code to begin/end EntityManager
> transactions explicitly.
>
> On 6/21/2013 11:10 AM, Jason Greene wrote:
>> Awesome. Thanks guys.
>> On Jun 19, 2013, at 6:58 PM, Shane Bryzak <sbryzak at redhat.com> wrote:
>>
>>> I've created a JIRA issue to track this work:
>>>
>>> https://issues.jboss.org/browse/PLINK-202
>>>
>>> On 20/06/13 00:22, Pete Muir wrote:
>>>> Shane and I spent time working through this earlier today. We think we can move all IDM APIs to stateless access, passing in the lightweight SecurityContext object to calls.
>>>>
>>>> Shane is going to work on it this week I think.
>>>>
>>>> On 13 Jun 2013, at 17:16, Jason Greene
>>>> <jason.greene at redhat.com>
>>>>    wrote:
>>>>
>>>>
>>>>> The IDM apis should be designed to support stateless access and not require any form of synchronization, volatiles, or CAS. It's fine however to have caching plugins which do keep state and are designed for concurrent access. However, those should be implemented using near-lockless strategies. I can help with that if you need it.
>>>>>
>>>>> On Jun 13, 2013, at 8:15 AM, Shane Bryzak
>>>>> <sbryzak at redhat.com>
>>>>>    wrote:
>>>>>
>>>>>
>>>>>> Do you mean DefaultStoreFactory.createIdentityStore() ?  I actually
>>>>>> don't think we should be caching the stores here at all, I'll create a
>>>>>> JIRA to investigate this.
>>>>>>
>>>>>> On 13/06/13 22:27, Bill Burke wrote:
>>>>>>
>>>>>>> IdentityManagerFactory's fields are all HashMaps and you're populating
>>>>>>> the store cache on the fly.  Is there any reason you don't
>>>>>>> pre-initialize the store cache?
>>>>>>>
>>>>>>> On 6/12/2013 6:22 PM, Shane Bryzak wrote:
>>>>>>>
>>>>>>>> IdentityManagerFactory is designed to be application-scoped (or even
>>>>>>>> container scoped), while IdentityManager is a lightweight object that is
>>>>>>>> designed to be request-scoped (as each IdentityManager has its own
>>>>>>>> SecurityContext with potential references to short-lived objects, such
>>>>>>>> as entity managers).  Which concurrency issues have you found?  We
>>>>>>>> should raise issues in JIRA to address these before we hit final.
>>>>>>>>
>>>>>>>> On 13/06/13 07:26, Bill Burke wrote:
>>>>>>>>
>>>>>>>>> How should concurrent access to IDM storage be handled?  Right now I see
>>>>>>>>> a lot of concurrency issues in the code that will pretty much force you
>>>>>>>>> to create an IdentityManagerFactory and IdentityManager per request.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> security-dev mailing list
>>>>>>>>
>>>>>>>> security-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>