Query every time or no need to query every time for each user action

Realistically, both options mean hitting the database.  I assume when you say "session", you don't mean some stored cache in the user's session cookies, but rather checking the session information stored on the server side.  Typically, that information is stored in the database.  So, either way, you're hitting the database to get data on the current user.

So then the question becomes, "Should I read the permissions from the permissions table, or should I depend on a 'cached' version inside the session table?"  While the answer depends heavily on your project's requirements, I would, by default, lean towards hitting the permissions.  You have to weigh the convenience of using a cached version vs the inconvenience of a full query against the permissions tables.  

In terms of security, it is best to always use fresh data.  Caching security information is a good way to incorporate hard-to-find vulnerabilities into your application.  Also, hitting the permissions table directly means you're virtually guaranteed to have good information.  On the other hand, it may be that your security needs are not very stringent, compared to an excessively expensive set of queries to get the live permissions.  In that case, maybe storing them in session is appropriate.  There's also a middle-of-the-road approach, in which you depend on a cached version, if present, and fall back to the live permissions if necessary.  When a security option changes, you clear the cached versions for all relevant logins.  That's a bit more management, but it is a happy compromise between the two options, if implemented well.

So which one would suggest and which one would be the best out of it?

Can we maintain a global hash map and store the user details ??? Example to store last update date+time per role in memory and in user session. When an administrator updates role permissions, you set 'update date+time' for this role to 'now'. Also, for each user action, you first check whether 'load date+time' for their role stored in their session is older than that global update date+time stored in memory. If it is older, then you need to reload role and its permissions from database.

I've provided some options for you, but you'll have to decide which way makes more sense in the context of your application and your security needs.  If you're really sensitive about session security, use the "read it live" method.  If you're more concerned with the expense of compiling permissions on every request, use the cache.  The "compromise" option is a little of both.

Your hash map idea is fine, but ultimately will not save you that much effort.  You'd still need to compile the hash tables and create code to manage it - that is probably the same amount of effort as checking the last modified flag on your permissions/user records.  What benefits would you derive from separating that data into its own lookup?  It could, in theory, provide a few milliseconds of performance, but it would not make a real difference to you or your users unless you're in the mega-traffic arena.

i'm planning to maintain the permissions in the hash table...assume i have 1 lakh users....How much bytes we can store maximum in the hashmap ??? How much big size it can have in production always ???

That really depends on your environment.  How much resources do you have available for it?  Will using those resources artificially limit the performance of other threads or processes?

You are asking about performance metrics which are tightly bound to the environment in which they are generated.  You'll need to code these solutions at least into your dev environment to understand how they will actually impact your application and your server.

can u share a few code snippet of how to deal with hashmap with less users? that would be helpful for me

I don't have a background in Java, so can't provide any help in that regard.  The system is generally pretty simple, though, and some quick experimentation can get you going in the right direction.