I have an application (full-stack) that is used millions of times concurrently.

Some vital application properties are managed on the client side (at the time it seemed to be the simplest approach to me), but of course this has security issues, so I have to manage all properties on the server side.

I was thinking on adding all these properties to a helper class I have that is public static. Since the client managed some of these properties I didn't have to worry about whether these properties were the right ones or not since they were per client. If they are on the server side I'm not sure any more how to be certain that the server is using the correct properties for X client.

How can I make sure that the correct properties are being used?

However, putting those properties on the helper class would prompt conflicts, no? Since many clients may access the same property. This would be bad.

The properties in question are to identify the application parameters. i.e. is the application for Photos? Is the application for Personal data? Is the application for my cart? It can be used in many parts of the website so I need to know which part so it can function properly. If I am in photos but it thinks I'm in personal data that is a problem.

I don't manage authentication of clients; it is a library that does that, so that is not an issue.

  • 3
    Could you describe what these properties are and what they're used for? To me it's not at all obvious that having them on the client is "simplest" but has "security issues" or that you only have to "worry about whether these properties were the right ones" when they're on the server; any or all of those premises might be wrong depending on what kinds of properties we're talking about. Also, how well can your server authenticate its clients? (since it sounds like that's a key part of this) – Ixrec Mar 31 '16 at 8:16
  • 1
    Sounds to me like all your problems stem from use of "static" – Esben Skov Pedersen Apr 30 '16 at 16:26

I think that you have to stand back and consider where you are going to persist the properties. The obvious place is in a database table indexed on clientID. How you map these properties to classes is a problem long solved by ORM frameworks (e.g. MyBatis and Hibernate in the Java space). It is highly unlikely that your properties will end up as static variables.

As far as threading goes, you need to lock access to any data structure that is accessed by multiple threads concurrently, where one or more threads may modify the structure. For instance:

  • If these properties are set up by SQL when a new customer comes on board, they are effectively read-only and no locking is needed.
  • If the client can modify these properties, and you allow multiple concurrent logins from the same client, then you need robust locking.
  • Similarly if a system admin can modify the properties while the client is logged in, then locking is again required.
  • Persistance on a database is not an option. I think I will opt for robust locking according to the httpwebcontext of each thread. I'll have to make a getter and setter that are threadsafe I fear... – Joze Mar 31 '16 at 8:45
  • @Joze 2 So there is no long-term storage, suggesting your properties only live for the length of the user session? If so, why not store them in the user session? – kiwiron Mar 31 '16 at 8:48
  • Yes exactly they only live for the user session and they are refreshed (through cache or through SQL query) if the session is renewed. I work in a very sensitive environment so I can only store some things in the user session, and there are other issues with storing in the user session, scalability etc... – Joze Mar 31 '16 at 9:22
  • Your comment does not seem to make sense. If a property can be "refreshed through an SQL query" then surely it is in a database? This implies that it has a lifetime greater than the current session. – kiwiron Apr 1 '16 at 8:46
  • It does. The point is not having to make the SQL queries to fetch those properties. – Joze Apr 4 '16 at 8:35

You have to identify each client - this might be IP address or a session ID passed in on every call or an authenticated token.

You store the properties either in memory or in a persisted store such as a database. You need to look up the properties on each request by the passed in identification.

So, all's simple and good as you now have a collection of properties keyed by users. Whether you need to lock this collection depends on concurrent access to the collection itself and the type of collection. You must lock the collection access, as you do not want to be searching through it to find a user's properties if another thread is removing a user's property. So you need to lock all reads and writes (you can use a more specialised read-write lock but start with a simple critical section at first)

If the properties that are stored are not dependant on the collection, eg they are in a map or dictionary or similar, then once you have found the properties you can return a reference to them for the rest of the request without further locking. ie you lock only to find the properties. If your collection might change the reference to the properties (eg adding a new entry before the one you have a reference to changes the referenced entry) then you will have to make a copy of them before releasing the lock.

I know this is all a 'it depends' answer, but in general for a resource shared among concurrent accesses, you need to lock that resource when it is being read or written to. For a collection, that means locking the collection when you add, remove or read an entry from it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.