4:26 p.m.
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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
5:22 p.m.
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.
7:27 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:15 a.m.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>
11:16 a.m.
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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
>>
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
9:22 a.m.
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(a)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(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>>
>
> _______________________________________________
> security-dev mailing list
> security-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
6:58 p.m.
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(a)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(a)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(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>>>
>> _______________________________________________
>> security-dev mailing list
>> security-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> security-dev mailing list
> security-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
10:10 a.m.
Awesome. Thanks guys.
On Jun 19, 2013, at 6:58 PM, Shane Bryzak <sbryzak(a)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(a)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(a)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(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>>>>
>>>>>
>>>>>
>>> _______________________________________________
>>> security-dev mailing list
>>>
>>> security-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/security-dev
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>>
>> _______________________________________________
>> security-dev mailing list
>>
>> security-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
3:39 p.m.
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(a)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(a)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(a)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(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>>>>>
>>>>>>
>>>>>>
>>>> _______________________________________________
>>>> security-dev mailing list
>>>>
>>>> security-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>> --
>>> Jason T. Greene
>>> WildFly Lead / JBoss EAP Platform Architect
>>> JBoss, a division of Red Hat
>>>
>>>
>>> _______________________________________________
>>> security-dev mailing list
>>>
>>> security-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/security-dev
>
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4:17 p.m.
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-a...
https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/picketlink-a...
https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/picketlink-a...
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(a)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(a)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(a)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(a)lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
4:21 p.m.
Doesn't help very much when you aren't running in a container...i.e.
when you're trying to authenticate/authorize in an Undertow handler.
On 6/21/2013 5:17 PM, Anil Saldhana wrote:
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-a...
https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/picketlink-a...
https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/picketlink-a...
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(a)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(a)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(a)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(a)lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
5:05 p.m.
Hi Bill,
in your view, what should PicketLink do as you are operating in a
JavaSE (Non JTA) environment?
My understanding is that applications deal with transaction management
in a non container (non JTA) environment. Special consideration should
be given to the fact that entity managers are not thread safe.
http://docs.jboss.org/hibernate/orm/4.0/hem/en-US/html/transactions.html
Regards,
Anil
On 06/21/2013 04:21 PM, Bill Burke wrote:
Doesn't help very much when you aren't running in a
container...i.e.
when you're trying to authenticate/authorize in an Undertow handler.
On 6/21/2013 5:17 PM, Anil Saldhana wrote:
> 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-a...
>
https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/picketlink-a...
>
https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/picketlink-a...
>
> 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(a)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(a)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(a)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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
5:29 p.m.
On 6/21/2013 6:05 PM, Anil Saldhana wrote:
Hi Bill,
in your view, what should PicketLink do as you are operating in a
JavaSE (Non JTA) environment?
Maybe I need to clarify. In Wildfly, servlet authentication will not
happen within an EJB container, so no container managed transactions or
container managed entity managers.
My understanding is that applications deal with transaction
management
in a non container (non JTA) environment. Special consideration should
be given to the fact that entity managers are not thread safe.
http://docs.jboss.org/hibernate/orm/4.0/hem/en-US/html/transactions.html
This is what I'm trying to tell you and why I"m bringing this up in a
"concurrent access" email thread.
The servlet authentication layer should not care what the underlying
Identity store is. But the JPA identity store needs to be able to
create and destroy EntityManagers and entity manager transactions *per*
access, depending on the settings. I only see code for initialization,
ContextInitializer.
I think this is all backwards. IDMF hides the SecurityContext, when,
IMO, the SecurityContext should be exposed to the application, and
closed by the application when it is finished.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
5:40 p.m.
SHould really be something like this:
IdentityManagerFactory factory = ...;
SecurityContext context = factory.beginContext();
IdentityManager corporate = context.getRealm("Red Hat");
User user = corporate.getUser("bburke(a)redhat.com");
IdentityManager application = context.getTier("My Application");
Role role = application.getRole("admin");
corporate.grantRole(user, role);
context.commit();
context.close();
IMO also, there should be a rename:
SecurityContext -> IdentityContext
IdentityManagerFactory -> IdentityContextFactory
IdentityManager -> PartitionManager
The SecurityContext name has already been used in other APIs and kind of
conflicts.already exists.
On 6/21/2013 6:29 PM, Bill Burke wrote:
On 6/21/2013 6:05 PM, Anil Saldhana wrote:
> Hi Bill,
> in your view, what should PicketLink do as you are operating in a
> JavaSE (Non JTA) environment?
>
Maybe I need to clarify. In Wildfly, servlet authentication will not
happen within an EJB container, so no container managed transactions or
container managed entity managers.
> My understanding is that applications deal with transaction management
> in a non container (non JTA) environment. Special consideration should
> be given to the fact that entity managers are not thread safe.
> http://docs.jboss.org/hibernate/orm/4.0/hem/en-US/html/transactions.html
>
This is what I'm trying to tell you and why I"m bringing this up in a
"concurrent access" email thread.
The servlet authentication layer should not care what the underlying
Identity store is. But the JPA identity store needs to be able to
create and destroy EntityManagers and entity manager transactions *per*
access, depending on the settings. I only see code for initialization,
ContextInitializer.
I think this is all backwards. IDMF hides the SecurityContext, when,
IMO, the SecurityContext should be exposed to the application, and
closed by the application when it is finished.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4171
days inactive
4180
days old
13 comments
5 participants
participants (5)
-
Anil Saldhana -
Bill Burke -
Jason Greene -
Pete Muir -
Shane Bryzak