GRANT ALL PRIVILEGES ON MyDb.* to 'chinnu'@'%' WITH GRANT OPTION;

While % means any host, you probably did not see the behavior you expected.

MySQL performs access control in two stages. First, it tries to connect you with the username/password provided. Next, it checks if you have the privileges to perform your request. Entries in tables user, db and host of mysql database are used for access control.

Lets say this is our user table:

----------------------------------------------
Host      |  User
----------------------------------------------
%         |  root
%         |  chinnu
localhost |  root
localhost |  
----------------------------------------------

% in Host means ‘any host’ and blank in User means any user or anonymous user. Note that the value % is less specific when compared to value localhost. MySQL, when performing access control, sorts this table with the most-specific Host at the top. So, we have something like

-----------------------------------------
Host      |  User
-----------------------------------------
localhost |  root
localhost |   
%         |  chinnu
%         |  root
------------------------------------------

When chinnu tries to login from localhost, there are two matching rows. Guess what, the first match wins. This means that chinnu is effectively logged in as an anonymous user. The anonymous user may not have privileges for MyDb, hence the access denied errors.

How to verify?
If you managed to connect execute SELECT CURRENT_USER(). If you get result as @localhost and not chinnu@localhost, you have the issue described above.

How to solve this?
Solution-1: Grant privileges for ‘chinnu’@'localhost’ in addition to ‘chinnu’@'%’
Solution-2: Just get rid of the anonymous user.

Technorati Tags: mysql

• Adherence to the JMS specification.
• Performance and throughput. (I am using SonicMQ’s benchmarking guide as a basis.)
• Scalability
• Clustering and reliability
• Cost

And a few things that may/may-not be typical thrown in for good measure:

• Support for Dead Letter Queues (DLQ)
• Ease of manageability (UI Management Console, for example)
• Distributed transaction support
• Etc

So what’s so hard about this seemingly straightforward task? Well to start with most vendors don’t seem to publish much in the way of comparisons against their competitors. They provide plenty of information as to why you should choose them, but little in the way data that distinguishes them from their competition. All such comparisons that I have been able to obtain to date have concerned themselves with performance criteria only. Don’t get me wrong, performance is important, but so are any number of things.

The documentation provided by most vendors is equally lacking, or difficult to find, or simply non-existent.

As such, I am (frustratingly) left with having to download, install, learn and play with most of the vendor products. Sigh. Stay tuned to this one. I will update this entry with my findings.

Technorati Tags: java, jms, messaging, message queues, sonicmq