Announcement Announcement Module
Collapse
No announcement yet.
prepopulate acl cache Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • prepopulate acl cache

    I would like to prepopulate my acl cache with all the acls for a particular class within my domain.

    What would be the best we to introduce those rows from the ACL_OBJECT_IDENTITY table? I can write the sql quite easily. It just isn't clear to me where I should hook in to add the entries to the cache.

    thanks,

    craig

    ps. the problem is users assigned to very few of these objects, but there can be quite a number of them. I am ok with it not adjusting the where clause, and just doing post invocation filtering, because they are cached anyways (toplink). The default behaviour of the acl dao is slow because if there are 50 of these items, it executes 50 sql statements to get each objects acl list. I would rather just get them all in 1 big swoop...is my approach sound? suggestions would be appreciated.

  • #2
    My first instinct would be to write an InitializingBean that simply queried the wired AclManager, looping over each of your domain instances with a mock Authentication you create within the InitializingBean implementation. As such you're getting everything cached at application startup time. New domain objects you create during the application will presumably hit the AclManager as part of their security management, so they'll make it into the cache at that point. Does this sound feasible?

    Comment


    • #3
      how about load all user acls when they log in

      Ben,

      Part of the problem was that there is 70 of those key items, and i want to load the acls for all of them in 1 swoop, not n sql calls. I have also been looking at loading them via Toplink (that is what we use for o-r here), and that has caused me confusion, similar to the hibernate issues I think...all in all I really like it, and I think this will just give me a better understanding of the framework.

      I have been studying the Acl code, and I have another question. Do you think it is a good/bad idea to the load Acl's for a user, instead of for the secured object. For instance, when Joe logs in, or when he first hits a secure object, all his Acls are loaded. I haven't had the exposure that you have had to consider all the implications, regarding performance, scalability, etc.

      One thing that seems plausible about this is, that I could dump the Acl's when the users session is closed. Also, if I was tight on resources, I could even serialize the Acl's even in between request/response cycles...again if I needed it for scalability. As you know, this could be controlled via filters, or listeners.

      This seems like it would be a fair bit of work though, any comments?


      thanks,

      Craig

      Comment


      • #4
        Ben,

        For the first while we are going to have relavtively few acl's in the database. I feel comfortable caching them all either at startup, or when the first acl check is done.

        Could you suggest the easiest way i could accomplish this, with just 1 or 2 sql calls?

        thanks,
        Craig

        Comment


        • #5
          I got it working with 1 call. I made my own dao which did the load, and created the acls. I then overrode the AclManager, and did the load in the init. Seems to work ok, but I did have to write more code than I think I should have. When I get a little more familiar with it I will try and improve it.

          thanks.

          Craig

          Comment


          • #6
            Do you think it is a good/bad idea to the load Acl's for a user, instead of for the secured object
            The BasicAclEntryCache stores all of the ACLs associated with a given domain object instance, not just those for a particular user. Quoting BasicAclProvider:

            Code:
                    result = basicAclDao.getAcls(aclObjectIdentity);
            
                    if (result == null) {
                        SimpleAclEntry[] emptyAclEntries = {new SimpleAclEntry(RECIPIENT_FOR_CACHE_EMPTY,
                                    aclObjectIdentity, null, 0)};
                        basicAclEntryCache.putEntriesInCache(emptyAclEntries);
            
                        return null;
                    }
            
                    basicAclEntryCache.putEntriesInCache(result);
            As shown, the cache stores directly what was obtained from the BasicAclDao. Only the EffectiveAclsResolver understands how to filter out domain object instances for a given Authentication.

            Now I understand your problem a little better, my suggestion would be to write an InitializingBean that loads the ResultSet in one hit. Then inject the straight into the BasicAclEntryCache, using the code fragment pasted above as a guide. That way you are still only querying the database a single time, and you shouldn't need to write any custom DAO or modify any Acegi Security classes.

            Comment

            Working...
            X