Up to this point, the test application has been using the default bucket. This is because it is not using the binary protocol, and it is not authenticated. The default bucket on Membase can be useful when you first start out, but as you build more complex applications, you may want to partition your data into different buckets (see Figure 1) to improve fault tolerance by boosting replication or just so that one bucket can be cleared without affecting all of the data you have stored in other buckets. You may also want to partition your key space among several applications to avoid naming collisions.

Figure 1. Figure 1: Creating a private bucket.

Figure 1, shows the dialog in the Membase Web Console that demonstrates creating a new bucket called private with two replicas. Here you also choose a password to protect the bucket during SASL authentication. How do you access this bucket? You have already learned about how to make a binary SASL authenticated connection to Membase. If you use the bucket name as the username, and the password you provided when creating the bucket, you will connect to the private bucket for data storage. The following code would accomplish this:

// We have used private as the username and private as the password
// but you would not do this, you would be much smarter and use
// something much harder to guess.
AuthDescriptor ad = new AuthDescriptor(new String[]{"PLAIN"},
    new PlainCallbackHandler("private", "private"));

MemcachedClient c = new MemcachedClient(
    new ConnectionFactoryBuilder().setProtocol(Protocol.BINARY)
        .setAuthDescriptor(ad)
        .build(),
        AddrUtil.getAddresses(host));