summaryrefslogtreecommitdiff
path: root/source4/torture/rpc/remact.c
diff options
context:
space:
mode:
authorSimo Sorce <idra@samba.org>2010-02-18 15:11:25 -0500
committerSimo Sorce <idra@samba.org>2010-02-23 12:46:50 -0500
commit1203de99b178a2d7f6c7c6534c42d05242322fe3 (patch)
tree06ec84ac7e0fe21b01322c0517cabb04743dacf3 /source4/torture/rpc/remact.c
parent1d0938c629904e14c3769036d1a8d1a6d7b3f34b (diff)
downloadsamba-1203de99b178a2d7f6c7c6534c42d05242322fe3.tar.gz
samba-1203de99b178a2d7f6c7c6534c42d05242322fe3.tar.bz2
samba-1203de99b178a2d7f6c7c6534c42d05242322fe3.zip
s4:schannel merge code with s3
After looking at the s4 side of the (s)channel :) I found out that it makes more sense to simply make it use the tdb based code than redo the same changes done to s3 to simplify the interface. Ldb is slow, to the point it needs haks to pre-open the db to speed it up, yet that does not solve the lookup speed, with ldb it is always going to be slower. Looking through the history it is evident that the schannel database doesn't really need greate expanadability. And lookups are always done with a single Key. This seem a perfet fit for tdb while ldb looks unnecessarily complicated. The schannel database is not really a persistent one. It can be discared during an upgrade without causing any real issue. all it contains is temproary session data.
Diffstat (limited to 'source4/torture/rpc/remact.c')
0 files changed, 0 insertions, 0 deletions