+------------------------+
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
