cancel
Showing results for 
Search instead for 
Did you mean: 

custom behaviour class/object implementation

aweber1nj
Champ in-the-making
Champ in-the-making
From what I can tell, my custom behavior class gets instantiated only once, and that same java object is then re-used across all the calls for all the nodes I've tested with (whether it re-runs on the same node, or whether it's an entirely different node).

I'm curious as to how this would scale, and will it cause a severe bottleneck when possibly hundreds or thousands of users are trying to manage their documents and they might all be waiting for the same, single, instantiated java object to execute the registered policies?

Is there some kind of threshold or threading involved that I haven't seen yet?  If so, are there any additional rules to writing correct behaviors such that they remain thread-safe?

Thanks in advance,
AJ
2 REPLIES 2

aweber1nj
Champ in-the-making
Champ in-the-making
Does anyone have any insight into this???

As I monitor the logs, it seems like multiple threads are using the same object somehow?  That should not be.

Furthermore, a synchronized block is basically blocking execution and for whatever reason, never completes.  The first thread seems to enter the synchronized block fine, but the first thing it does (after logging that it's in the block) is use the nodeService (private object) and it doesn't seem to ever get that far - or that's where it stops.  The nodeService apparently is being blocked by the second thread?  So eventually, the second thread "catches up" and gets to the synchronized block and can not enter.  Since the first thread is blocked trying to use the nodeService (I think), it all comes to a screeching halt.

I am testing by uploading two files at a time.  It always blocks in the same place.  If I upload one file at a time, it works consistently.

If someone could tell me how these objects are instantiated per-thread, per-node, or whatever, I could maybe figure out what Alfresco is trying to do.

aweber1nj
Champ in-the-making
Champ in-the-making
Looking further, it may be that I need to leverage the RetryingTransactionInterceptor.

It looks like this can be leveraged using declaritive properties in the bean definition?

Does anyone have any examples – maybe they have done this in the past – of using the TransactionService to specify that your on… behavior methods should be transactional (Read/Write)?

EDIT: I tried some semblance of using a transaction (from one of the wiki pages), and it didn't help.
Part of the stack trace is:
org.springframework.dao.ConcurrencyFailureException: Failed to update node 1929; nested exception is org.springframework.dao.DeadlockLoserDataAccessException: 
### Error updating database.  Cause: org.postgresql.util.PSQLException: ERROR: deadlock detected
  Detail: Process 2804 waits for ShareLock on transaction 321827; blocked by process 2432.
Process 2432 waits for ExclusiveLock on tuple (144,34) of relation 16582 of database 16386; blocked by process 2804.
  Hint: See server log for query details.
### The error may involve alfresco.node.update_Node-Inline
### The error occurred while setting parameters
### Cause: org.postgresql.util.PSQLException: ERROR: deadlock detected
Appreciate it.
-AJ