Re: [Springframework-developer] new bean factory and application context features

[Colin S. <col...@ex...>]

Colin Sampaleanu wrote:

> Rod Johnson wrote:
>
>>> W/regards to redefining TransactionAttributeSourceEditor to allow for
>>> wildcards also in the classname, that's a useful feature, but the
>>> internal workings of the class would have to change. Right now, using a
>>> MethodMapTransactionAttributeSource, essentially all the methods of the
>>> specified classes get added to the transactional method map (if they
>>> match the method regex). So this approach wouldn't work for regexes at
>>> the class level. You'd probably have to do matches at runtime, with
>>> consequently slower performance (although I guess you could cache the
>>> hits and misses, to alleviate this, making the performance pretty well
>>> identical on second and subsequent calls to the same method). What do
>>> you think of this idea
>>>   
>>
>>
>> I prototyped such an approach a couple of months ago. The performance 
>> seemed
>> not too bad. I haven't committed it. However, maybe I should when I get
>> time, if people are interested.
>>  
>>
> I think this would be useful to some people (although the ability to 
> handle the 'all' case with another mechanism like the specialized 
> TransactionalAttributeSource would cover most of my needs)..
>
> If there are performance concerns, it could use a dual approach where 
> regexes on methods only (ie everything up to and including the class 
> name is specified) get handled as they do now, and other regexes get 
> handled with a runtime lookup with cache. My feeling is that the 
> runtime lookup with cache would perform well enough though. One 
> consideration is that the config semantics would change in terms of 
> typos. Right now MethodMapTransactionalAttributeSource gives you an 
> exception if you feed it a FQN which can't be resolved, or there are 
> no matching methods. I like the idea of detecting typos in this 
> fashion, if at all possible. Considering that your code may appear to 
> run fine even without the transaction, if you mess up the regex, I 
> think the error detection is valuable.  So if the code is extended, 
> maybe one way to do it would be to have two sets of properties, one 
> which behaves exactly like the present property (config time regexes 
> on methods only), and a new one which adds runtime regex matching on 
> the package and class portion as well.
>
> Regards,
> Colin

For the time being I have added a new class 
MatchAllwaysTransactionAttributeSource, which will always return the 
same TransactionAttribute (which may be set, otherwise it will default 
to PROPOGATION_REQUIRED).

I also tried to check in a unit test for it, but Eclipse barfed, then 
Tortoise as well on a re-attempt, with the error you get when there is a 
file in the attic wth the same name but a different case. This is 
definitely not the case, since this is a new file. Here's the error 
message from Tortoise. I don't know what to do since we don't have 
physical access to the repo to see what is going on.

-----
In D:\src\open\spring-colin\spring: cvs -q commit -m "add 
MatchAllwaysTransactionAttributeSource, which returns the same 
TransactionAttribute for all methods" 
test/org/springframework/transaction/interceptor/MatchAllwaysTransactionAttributeSourceTest.java
CVSROOT=:ext:co...@cv...:/cvsroot/springframework

cvs: hash.c:312: findnode: Assertion `key != ((void *)0)' failed.
cvs [server aborted]: received abort signal

Error, CVS operation failed

Tortoise Tip: This error can be caused because there used to be a file 
in the repository with a name differing only by case from the one you 
are adding. For example TEST.EXE rather than test.exe. To fix this go 
into the repository, or get your administrator to, and rename that file 
to have the same case. It will be in the Attic folder underneath the 
folder you are in. You will also need to get the local sandbox folder 
you are in out of CVS again, as it may have bogus entries to the 
misspelt filename.
-----