+------------------------+
Jasypt Users List
http://www.jasypt.org
+------------------------+
Hello Mike,
Yours certainly looks like a nice solution, well thought. And thanks
for explaining it.
Nevertheless, I will better go for a more generalist pool-based
solution in jasypt 1.6, as thread-local solutions can be very adequate
for web applications because of its one request - one thread nature,
but a little bit trickier at non-web applications where the use of
threads is quite more "free"...
Regards,
Daniel.
Mike Rowehl wrote:
+------------------------+
Jasypt Users List
http://www.jasypt.org
+------------------------+
Thanks for the reply! I had considered what you suggest about different
beans for the different columns, but in our particular application the
contention mostly hits one very high traffic table. I tested it out and it
improved things, but not by enough.
In the meantime I've hacked up an alternative version that:
- uses thread local storage for the encryptor and decryptor member variables
- separates the initialize() method into a one time initializer and thread
specific init that instantiates the thread local encryptor and decryptor
objects
- and then I removed the syncronize completely from the encryptor/decryptor
access cause each thread has it's own
I haven't tested it out too extensively yet, but it seems like it should
also be a clean solution (at least for cases where a high degree of
concurrency is required). Happy to share out the version I'm trying if
you're interested in it.
- Mike
dfernandez wrote:
+------------------------+
Jasypt Users List
http://www.jasypt.org
+------------------------+
Hello Mike,
Yes and no :-). It is true that Spring will treat your bean as as
singleton by default, unless you set a "prototype" scope to it... but
the fact is that jasypt's own hibernate encryption type uses the
encryptor as a singleton, always.... not exactly a singleton, but a
hibernate-type-instance-wide singleton.
If I understood correctly, you are using the same encryptor to encrypt
more than one database column. If this is the case, I can give you a
workaround:
1st: If you only defined your StandardPBEStringEncryptor as a Spring
bean with the aim of passing it to the hibernate container
(HibernatePBEStringEncryptor), declare your encryptor as
"scope="prototype"". This way Spring will return a new instance of the
encryptor (with the same configuration) to each other object that asks
for it. (If you didn't define it only for this, maybe it's safer to
define a new prototye bean, with the same configuration as the original
one).
2nd: Define several "HibernatePBEStringEncryptor" beans, one for each
of your encrypted columns, and pass your StandardPBEStringEncryptor to
all of them, but setting a different "registeredName" for each. As you
defined your StandardPBEStringEncryptor as prototype, Spring will
provide a different instance of it to each of your
"HibernatePBEStringEncryptor"'s, and this way you will have several
instances of the encryptor with the same configuration, registered to be
used from hibernate under different names.
3rd: Define a different hibernate type (a typedef at the mapping file)
for each of your encrypted columns. Each of this typedefs will make use
of a different encryptor by setting a different
"encryptorRegisteredName". One typedef = one
HibernatePBEStringEncryptor. But all the encryptors being used will have
exactly the same configuration, and thus will be perfectly compatible
among them.
4th: Set a different type (typedef) for each of your encrypted
columns. This way, you will still have singletons... but at least just
one for each column. Performance should improve.
Anyway, this is just a workaround and this solution could be better...
you have made me thought about this issue, and I will probably try to
add some kind of "encryptor pooling" to the next version of jasypt to
avoid encryptors being a bottleneck.
Regards,
Daniel.
Mike Rowehl wrote:
+------------------------+
Jasypt Users List
http://www.jasypt.org
+------------------------+
Hey folks, I tried searching for this, but haven't found anything yet
(sorry
if it's there and I'm just looking for the wrong stuff). I have a
project
that's using the Hibernate initialization using Spring to provide the
encryptor, as described here:
http://jasypt.org/hibernate3.html
The code is working, encryption and decryption performed, peachy.
However,
when I have the system running within Tomcat I see very slow response
times
when there are multiple requests hitting encrypted columns. If I do a
thread dump when things are performing poorly I see a number of threads
all
waiting for the same decryptor object. Thead dump excerpt:
"http-5801-25" daemon prio=10 tid=0x0000000045ba2400 nid=0x2abd waiting
for
monitor entry [0x00000000461dd000..0x00000000461dfb10]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.jasypt.encryption.pbe.StandardPBEByteEncryptor.decrypt(StandardPBEByteEncryptor.java:784)
- waiting to lock <0x00002aaab33e0270> (a javax.crypto.Cipher)
at
org.jasypt.encryption.pbe.StandardPBEStringEncryptor.decrypt(StandardPBEStringEncryptor.java:639)
at
org.jasypt.hibernate.type.AbstractEncryptedAsStringType.nullSafeGet(AbstractEncryptedAsStringType.java:143)
at org.hibernate.type.CustomType.nullSafeGet(CustomType.java:105)
at org.hibernate.type.AbstractType.hydrate(AbstractType.java:81)
at
org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2096)
at org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1380)
at org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1308)
Many of the threads are waiting on exactly the same object it looks like.
I'm an admitted Spring/Hibernate/Tomcat noob, but I'm assuming what's
happening is that the encryptor being used by Hibernate is a singleton
cause
of the way Spring initializes it, and all the Tomcat threads are all
jammed
up waiting for the same object.
Am I misinterpreting what's going on, or does this seem likely? And if
so,
is there a different way to configure these objects so that I can avoid
contention on a shared resource? Thanks,
- Mike
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
jasypt-users mailing list
jasypt-users@...
https://lists.sourceforge.net/lists/listinfo/jasypt-users
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
jasypt-users mailing list
jasypt-users@...
https://lists.sourceforge.net/lists/listinfo/jasypt-users
